From: Thomas Zimmerman <thomas@zimres.net>
To: lkml <linux-kernel@vger.kernel.org>
Subject: Re: IO stats in /proc/partitions
Date: Sun, 5 May 2002 16:51:02 -0700 [thread overview]
Message-ID: <20020505235101.GA5060@darklands.zimres.net> (raw)
In-Reply-To: <200205051149.g45BnGX13620@Port.imtp.ilyichevsk.odessa.ua> <Pine.LNX.4.33.0205051027460.8663-100000@shell1.aracnet.com>
[-- Attachment #1: Type: text/plain, Size: 2197 bytes --]
On 05-May 11:10, M. Edward (Ed) Borasky wrote:
> On Sun, 5 May 2002, Denis Vlasenko wrote:
>
[snip]
> As you can probably guess, this sort of thing is one of the issues that
> my "COUGAR" proposal corrects. I leave design issues to the designers,
> but one thing I insist on is that there *be* requirements --
> *documented* requirements -- and a *documented* and debated design
> *before* hacking the code into the kernel and making implementation
> decisions.
...and here is where you sliped the track. Linux is designed by those
who post patches and lobby for thier use. If something doesn't work for
you post *patches* that fix it. Complaints that you don't have time to
work around current code gets you nothing.
As far as I can see, the reason that staticis now live in
/proc/partitions is that there was code _submitted_ (the sar patches)
to collect the staticis. If you have a better patch I, for one, would
love to see it. I don't think IO statistics shareing /proc/partitons
is great *design* but it was thought it would break the least tools
out there.
>
> Of course, since I would be the designer of at least part of "COUGAR", I
> would be making some of those decisions. Unfortunately, I have limited
> time to work on "COUGAR" until maybe late July, so if someone wants to
> pick up some of the balls and run with them, I'm willing to unload them.
> (Apologies if my metaphor jars those of you who live where football is
> played without the use of hands :).
>
> This is a process I highly recommend for performance-determining parts
> of Linux, like memory management and the scheduler. I know the memory
> management and scheduler gurus -- Rik, Andrea, Ingo and others -- *have*
> designs in their heads, *have* requirements that they're working to -- I
> just think we should be sharing and debating *those* on the list instead
> of just code and benchmark results.
Everyone loves the debate, but if no code is ever show all we get out of
it _is_ the debate. How many times has this happened on this subject
(widely taken as the /proc/* debate)? I've seen lots of hot air, but
little code.
Just my take,
Thomas Zimmerman
[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]
next prev parent reply other threads:[~2002-05-06 0:05 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-05-04 19:59 IO stats in /proc/partitions Andries.Brouwer
2002-05-04 20:35 ` M. Edward Borasky
2002-05-04 21:25 ` Mark Hahn
2002-05-05 1:04 ` M. Edward (Ed) Borasky
2002-05-06 14:04 ` Jakob Østergaard
2002-05-04 21:35 ` Tomas Szepe
2002-05-05 1:08 ` M. Edward (Ed) Borasky
2002-05-05 1:18 ` Mike Fedyk
2002-05-05 16:55 ` Denis Vlasenko
2002-05-05 18:10 ` M. Edward (Ed) Borasky
2002-05-05 23:51 ` Thomas Zimmerman [this message]
2002-05-04 22:53 ` Alan Cox
2002-05-04 22:46 ` H. Peter Anvin
2002-05-15 21:39 ` Marcelo Tosatti
2002-05-15 23:18 ` Miquel van Smoorenburg
2002-05-16 0:30 ` Alan Cox
2002-05-20 18:19 ` Bill Davidsen
2002-05-21 0:36 ` Guest section DW
2002-05-21 13:11 ` Alan Cox
2002-05-16 7:50 ` Christoph Hellwig
2002-05-23 20:27 ` Marcelo Tosatti
2002-05-24 9:56 ` Christoph Hellwig
-- strict thread matches above, loose matches on Subject: below --
2002-05-05 1:38 Nivedita Singhvi
2002-03-12 15:34 Jean-Eric Cuendet
2002-03-12 21:51 ` H. Peter Anvin
2002-03-12 22:48 ` Anton Altaparmakov
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=20020505235101.GA5060@darklands.zimres.net \
--to=thomas@zimres.net \
--cc=linux-kernel@vger.kernel.org \
/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;
as well as URLs for NNTP newsgroup(s).