Re: Knob turning on mtest01 for 2.4.13-pre5aa1

[bill davidsen]

In article <[e-mail]> [e-mail] wrote:

>Cool. this just proofs the vm_mapped_ratio logic is not worthwhile (I
>had similar results here so this just confirms).  So I'm killing it
>enterely (Linus was completly right that it wans't worthwhile). I'm also
>changing a bit the semantics of vm_balance_ratio (similar to pre3aa1)
>and I'm lowering it down due the slight change of semantics, plus I'm
>including the PG_launder (that resembles the PG_wait_for_IO logic in
>pre3aa1) and slightly modified BH_wait_IO logic from Linus. Hopefully
>the end result will be positive.
>
>Thanks very much for this great feedback! :)

  If you think that one test under one set of conditions proves that
user tuning is worthless, then remove OOM, as I can prove there are
cases where things work as well without it.

  To be honest I don't think that running a single player process while
running memory tests is representative of typical usage. Someone on a
small memory machine with memory pressure spread over multiple processes
would be better, and sudden program growth is also a reasonable thing to
expect, such as opening large files in an editor, entering a busy
newsgroup for the first time, opening a large image with gimp, etc.
These loads are things which users commonly do, and tuning parameters
for better responsiveness is certainly as valuable as running a test
with a numeric output. Sluggish system is one thing I do notice with
most Linux kernels on memory challenged machines.

  I think it would be worth waiting for a bit of additional feedback on
"feel" would be useful before adopting the Windows "system knows best"
approach.

-- 
bill davidsen <[e-mail]>
  His first management concern is not solving the problem, but covering
his ass. If he lived in the middle ages he'd wear his codpiece backward.