[lkml]   [2001]   [Jun]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: VM Report was:Re: Break 2.4 VM in five easy steps
    On Fri, 8 Jun 2001, John Stoffel wrote:

    > Mike> OK, riddle me this. If this test is a crummy test, just how is
    > Mike> it that I was able to warn Rik in advance that when 2.4.5 was
    > Mike> released, he should expect complaints? How did I _know_ that?
    > Mike> The answer is that I fiddle with Rik's code a lot, and I test
    > Mike> with this test because it tells me a lot. It may not tell you
    > Mike> anything, but it does me.
    > I never said it was a crummy test, please do not read more into my
    > words than was written. What I was trying to get across is that just
    > one test (such as a compile of the kernel) isn't perfect at showing
    > where the problems are with the VM sub-system.


    Tobias> Could you please explain what is good about this test? I
    Tobias> understand that it will stress the VM, but will it do so in a
    Tobias> realistic and relevant way?

    I agree, this isn't really a good test case. I'd rather see what
    happens when you fire up a gimp session to edit an image which is
    *almost* the size of RAM, or even just 50% the size of ram. Then how
    does that affect your other processes that are running at the same

    ...but anyway, yes it just one test from any number of possibles.

    > Jonathan Morton has been using another large compile to also test the
    > sub-system, and it includes a compile which puts a large, single
    > process pressure on the VM. I consider this to be a more
    > representative test of how the VM deals with pressure.

    What does 'more representative' mean given that the VM must react to
    every situation it runs into?

    > The kernel compile is an ok test of basic VM handling, but from what

    Now we're communicating. I never said it was more than that ;-)

    > I've been hearing on linux-kernel and linux-mm is that the VM goes to
    > crap when you have a mix of stuff running, and one (or more) processes
    > starts up or grows much larger and starts impacting the system
    > performance.
    > I'm also not knocking your contributions to this discussion, so stop
    > being so touchy. I was trying to contribute and say (albeit poorly)
    > that a *mix* of tests is needed to test the VM.

    Yes, more people need to test. I don't need to do all of those other
    tests (no have right toys), more people need to do repeatable tests.

    > More importantly, a *repeatable* set of tests is what is needed to
    > test the VM and get consistent results from run to run, so you can see
    > how your changes are impacting performance. The kernel compile
    > doesn't really have any one process grow to a large fraction of
    > memory, so dropping in a compile which *does* is a good thing.

    I know I'm only watching basic functionality. I'm watching basic
    functionality with one very consistant test run very consistantly.


    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 12:55    [W:0.023 / U:85.092 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site