Re: Linux Disk Performance/File IO per process

[List User]

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" <[e-mail]>
To: "List User" <[e-mail]>
Cc: "Chris Evans" <[e-mail]>; <[e-mail]>;
<[e-mail]>; <[e-mail]>; <[e-mail]>
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 [e-mail]
> Please read the FAQ at http://www.tux.org/lkml/
>