mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Daniel Phillips <phillips@bonn-fries.net>
To: "M. Edward Borasky" <znmeb@aracnet.com>,
	"Linux-Kernel@Vger. Kernel. Org" <linux-kernel@vger.kernel.org>
Subject: Re: Which is better at vm, and why? 2.2 or 2.4
Date: Sat, 20 Oct 2001 02:38:52 +0200	[thread overview]
Message-ID: <20011020003812Z16243-4005+727@humbolt.nl.linux.org> (raw)
In-Reply-To: <HBEHIIBBKKNOBLMPKCBBKEOIDOAA.znmeb@aracnet.com>
In-Reply-To: <HBEHIIBBKKNOBLMPKCBBKEOIDOAA.znmeb@aracnet.com>

On October 13, 2001 08:06 pm, M. Edward Borasky wrote:
> Linux certainly has the measurement capabilities; I've been able to find
> everything I need in /proc for the monitoring and analysis I need to do. On
> the control knobs, I think Linux falls short relative to, say, Solaris,
> Tru64, VMS and Windows 2000. Nearly all decisions seem to be "hard-wired" in
> Linux, for example, the goodness boosts given to processes to promote soft
> affinity, the time slice, and the fractions of memory allocated to the
> various functions: buffers, cached, etc. They are set as #defines in header
> files. Even having them as variables would be an improvement; then they
> could be examined and modified with a debugger.

It's because Linus wants it that way, with a view to encouraging the 
development of algorithms that work well across a broad range of 
configurations without requiring a lot of tuning.  So it's a case of short 
term pain for long term gain.

Keep in mind that once you start exposing tuning parameters you tend to get 
lots of user programs out there that break without the parameters, or if the 
parameters don't behave the same way across versions.  Official tuning 
parameters also get in the way of trying out new algorithms, which might not 
even support the old tweaks, for example.

> I would like to be able to set up a test system in my laboratory, fire up a
> benchmark that emulates a real-world workload and tweak these parameters
> somewhere in /proc in real time, while watching the response times of my
> benchmark transactions. I can do this in Tru64, I can do this in a number of
> other operating systems. Right now, for all practical purposes, when I want
> to perform an experiment like this, I need to recompile, quite often, the
> *entire* kernel, reboot and re-run my benchmark. In other words, if the
> parameters were tunable, what now takes *days* to do could be accomplished
> in hours, even minutes, with just a little up-front work.

So then you probably just want to grab one of the many patches that expose 
things through proc and use it as a jumping-off point to expose your own 
tweaks.  As you say, much faster than recompiling every time.

--
Daniel

  parent reply	other threads:[~2001-10-20  0:37 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-10-13 17:02 Patrick McFarland
2001-10-13 17:16 ` Alan Cox
2001-10-13 18:06   ` M. Edward Borasky
2001-10-13 18:17     ` Patrick McFarland
2001-10-13 18:29       ` Rik van Riel
2001-10-13 18:42         ` Patrick McFarland
2001-10-13 18:53           ` Patrick McFarland
2001-10-13 18:58             ` Rik van Riel
2001-10-13 19:04               ` Patrick McFarland
2001-10-13 19:10                 ` Rik van Riel
2001-10-13 19:28             ` Wilson
2001-10-13 20:12               ` [solid]
2001-10-13 20:21               ` Patrick McFarland
2001-10-13 19:17           ` Rik van Riel
2001-10-13 18:37       ` M. Edward Borasky
2001-10-20  0:38     ` Daniel Phillips [this message]
2001-10-20  1:05     ` Robert Love
2001-10-20 19:56       ` Mike Fedyk
2001-10-20 20:03       ` Robert Love
2001-10-13 17:48 ` Mark Hahn
2001-10-13 21:29   ` Mike Fedyk
2001-10-13 21:47     ` Mark Hahn
     [not found] <20011013132327.F249@localhost>
     [not found] ` <E15sSey-0003Jf-00@the-village.bc.nu>
2001-10-13 17:33   ` Patrick McFarland
     [not found]     ` <E15sSti-0003ME-00@the-village.bc.nu>
2001-10-13 17:49       ` Patrick McFarland

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=20011020003812Z16243-4005+727@humbolt.nl.linux.org \
    --to=phillips@bonn-fries.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=znmeb@aracnet.com \
    /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®