lkml.org 
[lkml]   [2002]   [Oct]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: writepage return value check in vmscan.c
    chrisl@vmware.com wrote:
    >
    > On Fri, Oct 25, 2002 at 11:44:14AM -0700, Andrew Morton wrote:
    > > chrisl@vmware.com wrote:
    > > >
    > > > bigmm -i 3 -t 2 -c 1024
    > >
    > > That's a nice little box killer you have there.
    >
    > Thanks. It kills on all our customer's kernel, they don't use the
    > bleeding edge kernel at all. It is interesting to see vmware
    > serve as some heavy load stress test tool. It will give some real
    > world load to the OS, e.g. the load need to boot a windows etc. You
    > can stack many of them to abuse the OS.

    I tested Andrea's latest kernel. It survived.

    Probably because it left 100 megabytes of lowmem unallocated
    throughout the test.

    > >
    > > With mem=4G, running bigmm -i 5 -t 2 -c 1024:
    > >
    > > 2.4.19: Ran for a few minutes, got slower and slower and
    > > eventually stopped. kupdate had taken 30 seconds CPU and
    > > all CPUs were spinning in shrink_cache(). Had to reset.
    > >
    > > 2.4.20-pre8-ac1: Ran for a minute, froze up for a couple of
    > > minutes then recovered and remained comfortable.
    >
    > How many instance of bigmm left there? It should be 10 bigmm
    > processes before oom kickin.

    Well, they should all be left running? All this memory has
    file-backing, and is easily reclaimable.

    umm, yes. There could be bogus oom-killings in the combined-LRU
    VMs. But I saw none in testing.



    All of which is great fun, but it leaves open the question "what
    the heck can vmware do about it". I wish there was a clear answer.

    If the customer is running a suse/UL kernel they're presumably OK.

    If their kernel comes from kernel.org they should add Andrea's patch.
    Which means they get an absolute boatload of stuff which they may
    not want:
    1223 files changed, 306053 insertions(+), 9655 deletions(-)
    but that kernel performs well.

    If they're running an RH-rmap kernel then they're probably okayish,
    although I'd recommend more testing there.

    If they're running an RHAS-style kernel then I do not know. It may
    fail.
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2005-03-22 13:30    [W:0.025 / U:29.580 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site