From owner-csa@oss.sgi.com Wed Jan 24 14:19:39 2001 Received: by oss.sgi.com id ; Wed, 24 Jan 2001 14:19:19 -0800 Received: (from localhost user: 'qarce', uid#10141) by oss.sgi.com with ESMTP id ; Wed, 24 Jan 2001 14:18:57 -0800 Date: Wed, 24 Jan 2001 14:18:57 -0800 (PST) From: Quentin Arce To: csa@oss.sgi.com Subject: checking for system errors Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-csa@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;csa-outgoing checking -------------------- Quentin Arce qarce@engr.sgi.com Linux Scalability Pager:(925) 472-2007 Admin. oss.sgi.com Office:(650) 933-3771 From owner-csa@oss.sgi.com Sun Jan 28 18:03:54 2001 Received: by oss.sgi.com id ; Sun, 28 Jan 2001 18:03:45 -0800 Received: from ns.virtualhost.dk ([195.184.98.160]:61964 "EHLO virtualhost.dk") by oss.sgi.com with ESMTP id ; Sun, 28 Jan 2001 18:03:29 -0800 Received: from burns.home.kernel.dk ([192.168.0.2]) by virtualhost.dk with esmtp (Exim 3.16 #1) id 14N3em-0007My-00; Mon, 29 Jan 2001 03:03:00 +0100 Received: from axboe by burns.home.kernel.dk with local (Exim 3.13 #1 (Debian)) id 14N3ef-0003xk-00; Mon, 29 Jan 2001 03:02:53 +0100 Date: Mon, 29 Jan 2001 03:02:52 +0100 From: Jens Axboe To: Tony.Young@ir.com Cc: slug@slug.org.au, csa@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: Linux Disk Performance/File IO per process Message-ID: <20010129030252.I12772@suse.de> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: ; from Tony.Young@ir.com on Mon, Jan 29, 2001 at 12:54:00PM +1100 Sender: owner-csa@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;csa-outgoing On Mon, Jan 29 2001, Tony.Young@ir.com wrote: > All, > > I work for a company that develops a systems and performance management > product for Unix (as well as PC and TANDEM) called PROGNOSIS. Currently we > support AIX, HP, Solaris, UnixWare, IRIX, and Linux. > > I've hit a bit of a wall trying to expand the data provided by our Linux > solution - I can't seem to find anywhere that provides the metrics needed to > calculate disk busy in the kernel! This is a major piece of information that > any mission critical system administrator needs to successfully monitor > their systems. The stock kernel doesn't provide either, but at least with Stephen's sard patches you can get system wide I/O metrics. ftp.linux.org.uk/pub/linux/sct/fs/profiling -- Jens Axboe From owner-csa@oss.sgi.com Sun Jan 28 18:04:54 2001 Received: by oss.sgi.com id ; Sun, 28 Jan 2001 18:04:34 -0800 Received: from ferret.lmh.ox.ac.uk ([163.1.138.204]:44038 "HELO ferret.lmh.ox.ac.uk") by oss.sgi.com with SMTP id ; Sun, 28 Jan 2001 18:04:27 -0800 Received: (qmail 22791 invoked by uid 501); 29 Jan 2001 02:04:15 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 29 Jan 2001 02:04:15 -0000 Date: Mon, 29 Jan 2001 02:04:15 +0000 (GMT) From: Chris Evans X-Sender: To: cc: , , Subject: Re: Linux Disk Performance/File IO per process In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-csa@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;csa-outgoing On Mon, 29 Jan 2001 Tony.Young@ir.com wrote: > All, > > I work for a company that develops a systems and performance management > product for Unix (as well as PC and TANDEM) called PROGNOSIS. Currently we > support AIX, HP, Solaris, UnixWare, IRIX, and Linux. > > I've hit a bit of a wall trying to expand the data provided by our Linux > solution - I can't seem to find anywhere that provides the metrics needed to > calculate disk busy in the kernel! This is a major piece of information that > any mission critical system administrator needs to successfully monitor > their systems. Stephen Tweedie has a rather funky i/o stats enhancement patch which should provide what you need. It comes with RedHat7.0 and gives decent disk statistics in /proc/partitions. Unfortunately this patch is not yet in the 2.2 or 2.4 kernel. I'd like to see it make the kernel as a 2.4.x item. Failing that, it'll probably make the 2.5 kernel. Cheers Chris From owner-csa@oss.sgi.com Sun Jan 28 23:40:55 2001 Received: by oss.sgi.com id ; Sun, 28 Jan 2001 23:40:46 -0800 Received: from ir.com.au ([210.8.187.18]:11715 "EHLO ir_nt_server2.ir.com.au") by oss.sgi.com with ESMTP id ; Sun, 28 Jan 2001 23:40:32 -0800 Received: by ir_nt_server2 with Internet Mail Service (5.5.2650.21) id ; Mon, 29 Jan 2001 12:54:01 +1100 Message-ID: From: Tony.Young@ir.com To: slug@slug.org.au Cc: csa@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Linux Disk Performance/File IO per process Date: Mon, 29 Jan 2001 12:54:00 +1100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-csa@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;csa-outgoing All, I work for a company that develops a systems and performance management product for Unix (as well as PC and TANDEM) called PROGNOSIS. Currently we support AIX, HP, Solaris, UnixWare, IRIX, and Linux. I've hit a bit of a wall trying to expand the data provided by our Linux solution - I can't seem to find anywhere that provides the metrics needed to calculate disk busy in the kernel! This is a major piece of information that any mission critical system administrator needs to successfully monitor their systems. I've looked in /proc - it provides I/O rates, but no time related information (which is required to calculate busy%) I've looked in the 2.4 kernel source (drivers/block/ll_rw_blk.c,include/linux/kernel_stat.h - dk_drive* arrays) - but can only see those /proc I/O rates being calculated. Is this data provided somewhere that I haven't looked? Or does the kernel really not provide the data necessary to calculate a busy rate? I'm also interested in finding out file I/O metrics on a per process basis. The CSA project run by SGI (http://oss.sgi.com/projects/csa) seems to provide summarised I/O metrics per process using a loadable kernel module. That is, it provides I/O rates for a process, but not for each file open by that process. Are there any existing methods to obtain this data? If so, can someone point me in the right direction? If not, what is the possibility of 'people-in-the-know' working towards making these sort of metrics available from the kernel? Could some of these metrics be added to the CSA project? (directed at the CSA people of course.) I'm more than willing to put in time to get these metrics into the kernel. However, I'm new to kernel development, so it would take longer for me than for someone who knows the code. But if none of the above questions can really be answered I'd appreciate some direction as to where in the kernel would be a good place to calculate/extract these metrics. I believe that the lack of these metrics will make it difficult for Linux to move into the mission critical server market. For this reason I'm keen to see this information made available. Thank you all for any help you may be able to provide. I'm not actually subscribed to either the CSA or the linux-kernel mailing lists, so I'd appreciate being CC'ed on any replies. Thanks. Tony... -- Tony Young Senior Software Engineer Integrated Research Limited Level 10, 168 Walker St North Sydney NSW 2060, Australia Ph: +61 2 9966 1066 Fax: +61 2 9966 1042 Mob: 0414 649942 tony.young@ir.com www.ir.com From owner-csa@oss.sgi.com Mon Jan 29 05:27:27 2001 Received: by oss.sgi.com id ; Mon, 29 Jan 2001 05:27:18 -0800 Received: from ferret.lmh.ox.ac.uk ([163.1.138.204]:34575 "HELO ferret.lmh.ox.ac.uk") by oss.sgi.com with SMTP id ; Mon, 29 Jan 2001 05:26:53 -0800 Received: (qmail 18971 invoked by uid 501); 29 Jan 2001 13:26:40 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 29 Jan 2001 13:26:40 -0000 Date: Mon, 29 Jan 2001 13:26:40 +0000 (GMT) From: Chris Evans X-Sender: To: cc: , , , Subject: RE: Linux Disk Performance/File IO per process In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-csa@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;csa-outgoing On Mon, 29 Jan 2001 Tony.Young@ir.com wrote: > Thanks to both Jens and Chris - this provides the information I need to > obtain our busy rate > It's unfortunate that the kernel needs to be patched to provide this > information - hopefully it will become part of the kernel soon. > > I had a response saying that this shouldn't become part of the kernel due to > the performance cost that obtaining such data will involve. I agree that a > cost is involved here, however I think it's up to the user to decide which > cost is more expensive to them - getting the data, or not being able to see > how busy their disks are. My feeling here is that this support could be user > configurable at run time - eg 'cat 1 > /proc/getdiskperf'. Hi, I disagree with this runtime variable. It is unnecessary complexity. Maintaining a few counts is total noise compared with the time I/O takes. Cheers Chris From owner-csa@oss.sgi.com Mon Jan 29 07:25:58 2001 Received: by oss.sgi.com id ; Mon, 29 Jan 2001 07:25:49 -0800 Received: from dfmail.f-secure.com ([194.252.6.39]:49419 "HELO dfmail.f-secure.com") by oss.sgi.com with SMTP id ; Mon, 29 Jan 2001 07:25:37 -0800 Received: (qmail 14204 invoked by uid 0); 29 Jan 2001 15:25:30 -0000 Received: from fsav4im2.f-secure.com (HELO fsav4im2) (194.197.29.47) by dfmail.f-secure.com with SMTP; 29 Jan 2001 15:25:30 -0000 Received: from dfintra.f-secure.com ([194.197.29.8]:3326) (HELO dfintra.f-secure.com) by fsav4im2 ([194.197.29.47]:25) (F-Secure Anti-Virus for Internet Mail 5.0.53 Release) with SMTP; Mon, 29 Jan 2001 15:27:31 -0000 Received: (qmail 17787 invoked from network); 29 Jan 2001 15:25:28 -0000 Received: from unknown (HELO fs131-224.f-secure.com) (10.128.131.224) by dfintra.f-secure.com with SMTP; 29 Jan 2001 15:25:28 -0000 Date: Mon, 29 Jan 2001 17:39:50 +0200 (MET DST) From: Szabolcs Szakacsits To: Chris Evans cc: , , , Subject: Re: Linux Disk Performance/File IO per process In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-csa@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;csa-outgoing On Mon, 29 Jan 2001, Chris Evans wrote: > Stephen Tweedie has a rather funky i/o stats enhancement patch which > should provide what you need. It comes with RedHat7.0 and gives decent > disk statistics in /proc/partitions. Monitoring via /proc [not just IO but close to anything] has the features: - slow, not atomic, not scalable - if kernel decides explicitely or due to a "bug" to refuse doing IO, you get something like this [even using a mlocked, RT monitor], procs memory swap io system cpu r b w swpd free buff cache si so bi bo in cs us sy id 0 1 1 27116 1048 736 152832 128 1972 2544 869 44 1812 2 43 55 5 0 2 27768 1048 744 153372 52 1308 2668 777 43 1772 2 61 37 0 2 1 28360 1048 752 153900 332 564 2311 955 49 2081 1 68 31 1 7 2 28356 1048 752 153708 3936 0 2175 29091 494 27348 0 1 99 1 0 2 28356 1048 792 153656 172 0 7166 0 144 838 4 17 80 In short, monitoring via /proc is unreliable. Szaka From owner-csa@oss.sgi.com Mon Jan 29 10:28:49 2001 Received: by oss.sgi.com id ; Mon, 29 Jan 2001 10:28:39 -0800 Received: from www.wen-online.de ([212.223.88.39]:29200 "EHLO wen-online.de") by oss.sgi.com with ESMTP id ; Mon, 29 Jan 2001 10:28:13 -0800 Received: from mikeg.weiden.de [212.63.145.39] by wen-online.de with ESMTP (SMTPD32-5.05) id A8E2B99D01B0; Mon, 29 Jan 2001 19:39:30 +0100 Received: from localhost (mikeg@localhost) by mikeg.weiden.de (8.8.3/8.8.3) with ESMTP id SAA01444; Mon, 29 Jan 2001 18:27:51 GMT X-Authentication-Warning: mikeg.weiden.de: mikeg owned process doing -bs Date: Mon, 29 Jan 2001 19:27:51 +0100 (CET) From: Mike Galbraith X-Sender: mikeg@mikeg.weiden.de To: Szabolcs Szakacsits cc: Chris Evans , Tony.Young@ir.com, slug@slug.org.au, csa@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: Linux Disk Performance/File IO per process In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-csa@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;csa-outgoing On Mon, 29 Jan 2001, Szabolcs Szakacsits wrote: > On Mon, 29 Jan 2001, Chris Evans wrote: > > > Stephen Tweedie has a rather funky i/o stats enhancement patch which > > should provide what you need. It comes with RedHat7.0 and gives decent > > disk statistics in /proc/partitions. > > Monitoring via /proc [not just IO but close to anything] has the > features: > - slow, not atomic, not scalable > - if kernel decides explicitely or due to a "bug" to refuse doing > IO, you get something like this [even using a mlocked, RT monitor], > procs memory swap io system cpu > r b w swpd free buff cache si so bi bo in cs us sy id > 0 1 1 27116 1048 736 152832 128 1972 2544 869 44 1812 2 43 55 > 5 0 2 27768 1048 744 153372 52 1308 2668 777 43 1772 2 61 37 > 0 2 1 28360 1048 752 153900 332 564 2311 955 49 2081 1 68 31 > > 1 7 2 28356 1048 752 153708 3936 0 2175 29091 494 27348 0 1 99 > 1 0 2 28356 1048 792 153656 172 0 7166 0 144 838 4 17 80 > > In short, monitoring via /proc is unreliable. Not really unreliable, but definitely with _serious_ latency issues :) due to taking the mmap_sem. Acquiring the mmap_sem semaphore can take a really long time under load.. and sys_brk downs this semaphore first thing, as does task_mem() and proc_pid_stat()... If someone has the mmap_sem you want, and is pushing disk I/O when that disk is saturated, you are in for a long wait. This I think is what you see with your mlocked RT monitor (pretty similar to my mlocked RT monitor I suspect) In fact, that darn monitor can have a decidedly negative impact on system performance because it can take an arbitrary task's mana connection and then fault while throttling it... I think ;-) -Mike From owner-csa@oss.sgi.com Mon Jan 29 14:45:00 2001 Received: by oss.sgi.com id ; Mon, 29 Jan 2001 14:44:51 -0800 Received: from dns2.chaven.com ([207.238.162.18]:28318 "EHLO shell.chaven.com") by oss.sgi.com with ESMTP id ; Mon, 29 Jan 2001 14:44:36 -0800 Received: from stcostlnds2zxj (angrboda.chaven.com [207.238.162.3]) by shell.chaven.com (8.11.1/8.11.1) with SMTP id f0TMgaH22162; Mon, 29 Jan 2001 16:42:36 -0600 Message-ID: <037d01c08a44$9bb9ace0$160912ac@stcostlnds2zxj> From: "List User" To: "Chris Evans" , Cc: , , , References: Subject: Re: Linux Disk Performance/File IO per process Date: Mon, 29 Jan 2001 16:41:18 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-csa@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;csa-outgoing Just wanted to 'chime' in here. Yes this would be noisy and will have an affect on system performance however these statistics are what are used in conjunction with several others to size systems as well as to plan on growth. If Linux is to be put into an enterprise environment these types of statistics will be needed. When you start hooking up 100's of 'physical volumes' (be it real disks or raided logical drives) this data helps you pin-point problems. I think the idea of having the ability to turn such accounting on/off via /proc entry a very nice method of doing things. That way you can leave it off for normal run-time but when users complain or DBA's et al you can turn it on get some stats for a couple hours/days whatever, then turn it back off and plan an upgrade or re-create a logical volume or stripping set. Steve ----- Original Message ----- From: "Chris Evans" To: Cc: ; ; ; Sent: Monday, January 29, 2001 07:26 Subject: RE: Linux Disk Performance/File IO per process > > On Mon, 29 Jan 2001 Tony.Young@ir.com wrote: > > > Thanks to both Jens and Chris - this provides the information I need to > > obtain our busy rate > > It's unfortunate that the kernel needs to be patched to provide this > > information - hopefully it will become part of the kernel soon. > > > > I had a response saying that this shouldn't become part of the kernel due to > > the performance cost that obtaining such data will involve. I agree that a > > cost is involved here, however I think it's up to the user to decide which > > cost is more expensive to them - getting the data, or not being able to see > > how busy their disks are. My feeling here is that this support could be user > > configurable at run time - eg 'cat 1 > /proc/getdiskperf'. > > Hi, > > I disagree with this runtime variable. It is unnecessary complexity. > Maintaining a few counts is total noise compared with the time I/O takes. > > Cheers > Chris > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majordomo@vger.kernel.org > Please read the FAQ at http://www.tux.org/lkml/ > From owner-csa@oss.sgi.com Mon Jan 29 15:42:21 2001 Received: by oss.sgi.com id ; Mon, 29 Jan 2001 15:42:02 -0800 Received: from ir.com.au ([210.8.187.18]:62427 "EHLO ir_nt_server2.ir.com.au") by oss.sgi.com with ESMTP id ; Mon, 29 Jan 2001 15:41:39 -0800 Received: by ir_nt_server2 with Internet Mail Service (5.5.2650.21) id ; Mon, 29 Jan 2001 13:50:26 +1100 Message-ID: From: Tony.Young@ir.com To: chris@scary.beasts.org Cc: slug@slug.org.au, csa@oss.sgi.com, linux-kernel@vger.kernel.org Subject: RE: Linux Disk Performance/File IO per process Date: Mon, 29 Jan 2001 13:50:26 +1100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: owner-csa@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;csa-outgoing > -----Original Message----- > From: Chris Evans [mailto:chris@scary.beasts.org] > Sent: Monday, 29 January 2001 13:04 > To: Tony Young > Cc: slug@slug.org.au; csa@oss.sgi.com; linux-kernel@vger.kernel.org > Subject: Re: Linux Disk Performance/File IO per process > > > > On Mon, 29 Jan 2001 Tony.Young@ir.com wrote: > > > All, > > > > I work for a company that develops a systems and > performance management > > product for Unix (as well as PC and TANDEM) called > PROGNOSIS. Currently we > > support AIX, HP, Solaris, UnixWare, IRIX, and Linux. > > > > I've hit a bit of a wall trying to expand the data provided > by our Linux > > solution - I can't seem to find anywhere that provides the > metrics needed to > > calculate disk busy in the kernel! This is a major piece of > information that > > any mission critical system administrator needs to > successfully monitor > > their systems. > > Stephen Tweedie has a rather funky i/o stats enhancement patch which > should provide what you need. It comes with RedHat7.0 and gives decent > disk statistics in /proc/partitions. > > Unfortunately this patch is not yet in the 2.2 or 2.4 kernel. > I'd like to > see it make the kernel as a 2.4.x item. Failing that, it'll > probably make > the 2.5 kernel. > > Cheers > Chris > Thanks to both Jens and Chris - this provides the information I need to obtain our busy rate It's unfortunate that the kernel needs to be patched to provide this information - hopefully it will become part of the kernel soon. I had a response saying that this shouldn't become part of the kernel due to the performance cost that obtaining such data will involve. I agree that a cost is involved here, however I think it's up to the user to decide which cost is more expensive to them - getting the data, or not being able to see how busy their disks are. My feeling here is that this support could be user configurable at run time - eg 'cat 1 > /proc/getdiskperf'. Thanks for your quick responses. Tony... From owner-csa@oss.sgi.com Mon Jan 29 18:19:31 2001 Received: by oss.sgi.com id ; Mon, 29 Jan 2001 18:19:22 -0800 Received: from green.csi.cam.ac.uk ([131.111.8.57]:36768 "EHLO green.csi.cam.ac.uk") by oss.sgi.com with ESMTP id ; Mon, 29 Jan 2001 18:19:17 -0800 Received: from jas88 (helo=localhost) by green.csi.cam.ac.uk with local-esmtp (Exim 3.16 #1) id 14NQNb-0006Mp-00; Tue, 30 Jan 2001 02:18:47 +0000 Date: Tue, 30 Jan 2001 02:18:47 +0000 (GMT) From: James Sutherland X-Sender: jas88@green.csi.cam.ac.uk To: List User cc: Chris Evans , Tony.Young@ir.com, slug@slug.org.au, csa@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: Linux Disk Performance/File IO per process In-Reply-To: <037d01c08a44$9bb9ace0$160912ac@stcostlnds2zxj> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-csa@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;csa-outgoing On Mon, 29 Jan 2001, List User wrote: > Just wanted to 'chime' in here. Yes this would be noisy and will have > an affect on system performance however these statistics are what are > used in conjunction with several others to size systems as well as to > plan on growth. If Linux is to be put into an enterprise environment > these types of statistics will be needed. > > When you start hooking up 100's of 'physical volumes' (be it real > disks or raided logical drives) this data helps you pin-point > problems. I think the idea of having the ability to turn such > accounting on/off via /proc entry a very nice method of doing things. Question: how will the extra overhead of checking this configuration compare with just doing it anyway? If the code ends up as: if (stats_enabled) counter++; then you'd be better off keeping stats enabled all the time... Obviously it'll be a bit more complex, but will the stats code be able to remove itself completely when disabled, even at runtime?? Might be possible with IBM's dprobes, perhaps...? > That way you can leave it off for normal run-time but when users > complain or DBA's et al you can turn it on get some stats for a couple > hours/days whatever, then turn it back off and plan an upgrade or > re-create a logical volume or stripping set. NT allows boot-time (en|dis)abling of stats; they quote a percentage for the performance hit caused - 4%, or something like that?? Of course, they don't say whether that's a 486 on a RAID array or a quad Xeon on IDE, so the accuracy of that figure is a bit questionable... James. From owner-csa@oss.sgi.com Mon Jan 29 18:53:12 2001 Received: by oss.sgi.com id ; Mon, 29 Jan 2001 18:53:02 -0800 Received: from dns2.chaven.com ([207.238.162.18]:61086 "EHLO shell.chaven.com") by oss.sgi.com with ESMTP id ; Mon, 29 Jan 2001 18:52:43 -0800 Received: from stcostlnds2zxj (angrboda.chaven.com [207.238.162.3]) by shell.chaven.com (8.11.1/8.11.1) with SMTP id f0U2ofd23646; Mon, 29 Jan 2001 20:50:41 -0600 Message-ID: <007201c08a67$42a925e0$160912ac@stcostlnds2zxj> From: "List User" To: "James Sutherland" Cc: "Chris Evans" , , , , References: Subject: Re: Linux Disk Performance/File IO per process Date: Mon, 29 Jan 2001 20:49:21 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-csa@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;csa-outgoing It depends on what the performance hit is 'after coding'. If the code is say less than 5% overhead I honestly don't see there being a problem then just to compile it in the kernel and keep it active all the time. Only people who would need it would compile it in, and from experience 5% or less for the systems that would be keeping this data is negligible considering functionality/statistics gained. Steve ----- Original Message ----- From: "James Sutherland" To: "List User" Cc: "Chris Evans" ; ; ; ; Sent: Monday, January 29, 2001 20:18 Subject: Re: Linux Disk Performance/File IO per process > On Mon, 29 Jan 2001, List User wrote: > > > Just wanted to 'chime' in here. Yes this would be noisy and will have > > an affect on system performance however these statistics are what are > > used in conjunction with several others to size systems as well as to > > plan on growth. If Linux is to be put into an enterprise environment > > these types of statistics will be needed. > > > > When you start hooking up 100's of 'physical volumes' (be it real > > disks or raided logical drives) this data helps you pin-point > > problems. I think the idea of having the ability to turn such > > accounting on/off via /proc entry a very nice method of doing things. > > Question: how will the extra overhead of checking this configuration > compare with just doing it anyway? > > If the code ends up as: > > if (stats_enabled) > counter++; > > then you'd be better off keeping stats enabled all the time... > > Obviously it'll be a bit more complex, but will the stats code be able to > remove itself completely when disabled, even at runtime?? > > Might be possible with IBM's dprobes, perhaps...? > > > That way you can leave it off for normal run-time but when users > > complain or DBA's et al you can turn it on get some stats for a couple > > hours/days whatever, then turn it back off and plan an upgrade or > > re-create a logical volume or stripping set. > > NT allows boot-time (en|dis)abling of stats; they quote a percentage for > the performance hit caused - 4%, or something like that?? Of course, they > don't say whether that's a 486 on a RAID array or a quad Xeon on IDE, so > the accuracy of that figure is a bit questionable... > > > James. > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majordomo@vger.kernel.org > Please read the FAQ at http://www.tux.org/lkml/ > From owner-csa@oss.sgi.com Wed Jan 31 07:58:51 2001 Received: by oss.sgi.com id ; Wed, 31 Jan 2001 07:58:42 -0800 Received: from sgi.SGI.COM ([192.48.153.1]:11845 "EHLO sgi.com") by oss.sgi.com with ESMTP id ; Wed, 31 Jan 2001 07:58:32 -0800 Received: from zeus-fddi.americas.sgi.com (128-162-8-103.americas.sgi.com [128.162.8.103] (may be forged)) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id HAA09429 for ; Wed, 31 Jan 2001 07:58:31 -0800 (PST) mail_from (kohnke@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id JAA655473 for ; Wed, 31 Jan 2001 09:56:00 -0600 (CST) Received: from kenobi.americas.sgi.com (kenobi.americas.sgi.com [128.162.184.39]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id JAA46472 for ; Wed, 31 Jan 2001 09:55:59 -0600 (CST) Received: from kenobi.americas.sgi.com by kenobi.americas.sgi.com (SGI-8.9.3/SGI-client-1.7) via ESMTP id JAA24500; Wed, 31 Jan 2001 09:55:59 -0600 (CST) Message-Id: <200101311555.JAA24500@kenobi.americas.sgi.com> To: csa@oss.sgi.com From: kohnke@sgi.com (Marlys Kohnke) Subject: new Linux 2.4.0 CSA loadable module tarball Date: Wed, 31 Jan 2001 09:55:58 -0600 Sender: owner-csa@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;csa-outgoing Extended testing showed a problem using spinlocks in the CSA loadable module code. This code had been working with Linux 2.4.0-test7, but has occasional problems with the released Linux-2.4.0 code. The module spinlocks have been replaced with semaphores. We've run our automated tests continuously for three days and haven't seen any hangs using semaphores. The symptom is that the system still responds to a ping, but current login sessions and new login attempts are unresponsive. The problem occurs during a disk write of an accounting record. The loadable module tarball with the spinlocks has been moved into the download/old directory. A new tarball is available in the download directory, csa-module-2.4.0.tar.gz, from the download link at http://oss.sgi.com/projects/csa. I've also added a ChangeLog file to the download directory to document changes. ---- Marlys Kohnke Silicon Graphics Inc. kohnke@sgi.com 655F Lone Oak Drive (651)683-5324 Eagan, MN 55121 From owner-csa@oss.sgi.com Wed Jan 31 08:10:01 2001 Received: by oss.sgi.com id ; Wed, 31 Jan 2001 08:09:51 -0800 Received: from deliverator.sgi.com ([204.94.214.10]:33557 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Wed, 31 Jan 2001 08:09:41 -0800 Received: from sguk.reading.sgi.com (sguk.reading.sgi.com [144.253.64.2]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id IAA00315 for ; Wed, 31 Jan 2001 08:08:41 -0800 (PST) mail_from (mfoster@sgi.com) Received: from nt-reading1.reading.sgi.com (nt-reading1.reading.sgi.com [144.253.64.202]) by sguk.reading.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF.hoststrip-1.1) via ESMTP id QAA10279 for ; Wed, 31 Jan 2001 16:08:02 GMT Received: by nt-reading1.reading.sgi.com with Internet Mail Service (5.5.2650.21) id ; Wed, 31 Jan 2001 16:07:59 -0000 Message-ID: From: Martyn Foster To: csa@oss.sgi.com Subject: CSA for IA64? Date: Wed, 31 Jan 2001 16:07:58 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: owner-csa@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;csa-outgoing Hi, Has anyone made progress towards an IA64 port of csa? Any pitfalls we should be looking out for? Cheers, Martyn Martyn Foster Silicon Graphics Manchester, UK From owner-csa@oss.sgi.com Wed Jan 31 09:08:41 2001 Received: by oss.sgi.com id ; Wed, 31 Jan 2001 09:08:22 -0800 Received: from sgi.SGI.COM ([192.48.153.1]:4456 "EHLO sgi.com") by oss.sgi.com with ESMTP id ; Wed, 31 Jan 2001 09:08:11 -0800 Received: from zeus-fddi.americas.sgi.com (128-162-8-103.americas.sgi.com [128.162.8.103] (may be forged)) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id JAA05852 for ; Wed, 31 Jan 2001 09:08:10 -0800 (PST) mail_from (kohnke@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id LAA656215; Wed, 31 Jan 2001 11:05:36 -0600 (CST) Received: from kenobi.americas.sgi.com (kenobi.americas.sgi.com [128.162.184.39]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id LAA03759; Wed, 31 Jan 2001 11:05:36 -0600 (CST) Received: from kenobi.americas.sgi.com by kenobi.americas.sgi.com (SGI-8.9.3/SGI-client-1.7) via ESMTP id LAA25540; Wed, 31 Jan 2001 11:05:35 -0600 (CST) Message-Id: <200101311705.LAA25540@kenobi.americas.sgi.com> To: Martyn Foster From: kohnke@sgi.com (Marlys Kohnke) cc: csa@oss.sgi.com, watters@sgi.com Subject: Re: CSA for IA64? In-reply-to: Your message of "Wed, 31 Jan 2001 16:07:58 GMT." Date: Wed, 31 Jan 2001 11:05:34 -0600 Sender: owner-csa@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;csa-outgoing > Has anyone made progress towards an IA64 port of csa? Any pitfalls >we should be looking out for? I've started the ia64 port. I should have it available from oss.sgi.com/projects/csa for download within the next two weeks. What we've noticed so far is that system calls are handled differently. That is, we need to make some assembly language code changes to add new system calls. We didn't need to do this on ia32. So, the CSA commands which call the new syscall (acctctl for CSA) need to link in a new .o from the assembly language code in order for acctctl to be accessible. Sam Watters has this working for the ia64 PAGG job infrastructure system call. I'll use his assembly code procedure for CSA also to invoke acctctl. --- Marlys Kohnke Silicon Graphics Inc. kohnke@sgi.com 655F Lone Oak Drive (651)683-5324 Eagan, MN 55121