Linux-kernel mailing list archive 1998-48,: Re: disks stats through /proc

# Re: disks stats through /proc

Tigran Aivazian (tigran@aivazian.demon.co.uk)
Fri, 4 Dec 1998 15:17:53 +0000 (GMT)

- Messages sorted by: [ date ][ thread ][ subject ][ author ]
- Next message: Barry Zubel: "Re: Modular SysV IPC, testers wanted [patch]"
- Previous message: Myrdraal: "Re: schedule_timeout: wrong timeout value (A[nother] very poor bug-report)"

Thanks, I have got both of them.
I will have a detailed look at them this weekend.
However, instead of doing it in /proc/stat I will try to move it into
/proc/partitions - since we have /proc/partitions already (thanks to
Andries!) we might as well enhance it to include partition-level stats.

I will also study and play with Stephen Tweedie's sard stuff
which Alan Cox mentioned yesterday.

I think, as long as it does not harm performance, detailed performance
indicators in /proc would benefit everybody.

Regards,
Tigran

On Fri, 4 Dec 1998 kfrench@unitedis.com wrote:

> I had fixed up the scsi/ide/4drive limit a while ago, but it was never
> included. It was around the IO-APIC introduction time (i.e. more
> important things were 'broken') and there were rumblings of a code freeze.
>
> Grab
> http://pebbles.net/~kfrench/linux/blockstatarray-2.1.86.gz
> http://pebbles.net/~kfrench/linux/blockstatdirect-2.1.86.gz
>
> Each one does the same thing, but does it differently (apply *only* one of
> these, not both). 'array' hold a resizeable array for each device, and
> 'direct' creates a large array up-front for performance reasons. I like
> 'array' and Mark Lord likes 'direct'. It'll need a little fixing up to
> get it going on 2.1.130, but it shouldn't be a big deal. It's also
> trivial to do this on a partition level - it's just a matter of removing
> the switch() statement which intentionally removes the per-partition parts
> of a device #.
>
> -kf
>
> On Thu, 3 Dec 1998, Tigran Aivazian wrote:
>
> > IMHO, this should be done on a fine-grained (partition level) rather than
> > coarse (drive) level. There is enough information in
> > ll_rw_blk.c/add_request() to do it now but, of course, kernel_stat
> > structure will have to be seriously modified.
> >
> > There is something frustrating about the quality and speed of Linux
> > development. I.e. the quality is too high and the speed is too high, in
> > other words, I can implement this disk stat feature, but I bet someone else
> > has already done it and is just about to release his patch to Linus soon...
>
> heh
>

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

- Next message: Barry Zubel: "Re: Modular SysV IPC, testers wanted [patch]"
- Previous message: Myrdraal: "Re: schedule_timeout: wrong timeout value (A[nother] very poor bug-report)"