mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "List User" <lists@chaven.com>
To: "James Sutherland" <jas88@cam.ac.uk>
Cc: "Chris Evans" <chris@scary.beasts.org>, <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
Date: Mon, 29 Jan 2001 20:49:21 -0600	[thread overview]
Message-ID: <007201c08a67$42a925e0$160912ac@stcostlnds2zxj> (raw)
In-Reply-To: <Pine.SOL.4.21.0101300215050.21740-100000@green.csi.cam.ac.uk>

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" <jas88@cam.ac.uk>
To: "List User" <lists@chaven.com>
Cc: "Chris Evans" <chris@scary.beasts.org>; <Tony.Young@ir.com>;
<slug@slug.org.au>; <csa@oss.sgi.com>; <linux-kernel@vger.kernel.org>
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/
>

-
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/

  reply	other threads:[~2001-01-30  2:53 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-01-29  2:50 Tony.Young
2001-01-29 13:26 ` Chris Evans
2001-01-29 22:41   ` List User
2001-01-30  2:18     ` James Sutherland
2001-01-30  2:49       ` List User [this message]
  -- strict thread matches above, loose matches on Subject: below --
2001-01-29  1:54 Tony.Young
2001-01-29  2:02 ` Jens Axboe
2001-01-29  2:04 ` Chris Evans
2001-01-29 15:39   ` Szabolcs Szakacsits
2001-01-29 18:27     ` Mike Galbraith

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='007201c08a67$42a925e0$160912ac@stcostlnds2zxj' \
    --to=lists@chaven.com \
    --cc=Tony.Young@ir.com \
    --cc=chris@scary.beasts.org \
    --cc=csa@oss.sgi.com \
    --cc=jas88@cam.ac.uk \
    --cc=linux-kernel@vger.kernel.org \
    --cc=slug@slug.org.au \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®