linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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 --]

  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).