lkml.org 
[lkml]   [2002]   [Jul]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: Terrible VM in 2.4.11+ again?
    On Tue, Jul 09, 2002 at 12:48:08PM +0200, Lukas Hejtmanek wrote:
    > On Tue, Jul 09, 2002 at 12:58:16AM +0200, J.A. Magallon wrote:
    > > Seriously, if you have that kind of problems, take the -aa kernel and use it.
    > > I use it regularly and it behaves as one would expect, and fast.
    > > And please, report your results...
    >
    > I've tried 2.4.19rc1aa2, it swaps even when I have 512MB ram and xcdroast with
    > scsi-ide emulation cd writer reports to syslog:
    > Jul 9 12:45:02 hell kernel: __alloc_pages: 3-order allocation failed
    > (gfp=0x20/0)
    > Jul 9 12:45:02 hell kernel: __alloc_pages: 3-order allocation failed
    > (gfp=0x20/0)
    > Jul 9 12:45:02 hell kernel: __alloc_pages: 2-order allocation failed
    > (gfp=0x20/0)
    > Jul 9 12:45:02 hell kernel: __alloc_pages: 1-order allocation failed
    > (gfp=0x20/0)
    > Jul 9 12:45:02 hell kernel: __alloc_pages: 0-order allocation failed
    > (gfp=0x20/0)
    >
    > Am I something missing?

    you may want to reproduce with vm_debug set to 1, but I'm pretty sure
    it's a scsi generic issue, they are allocating ram with GFP_ATOMIC, and
    they may eventually fail if kswapd cannot keep up with the other
    GFP_ATOMIC allocations. They should use GFP_NOIO, with -aa it won't even
    try to unmap pages. It will just try to shrink clean cache and it
    should work fine for the above purpose where the allocation needs low
    latency (the local_pages per-task ensures their work won't be stolen by
    the GFP_ATOMIC users). I asked for that change some time ago but it
    never happened apparently. However I assume the sr layer tried some more
    after failing, sg has a quite large queue so some delay isn't fatal, and
    you can probably safely ignore the above messages, they're just warnings
    for you. nevertheless GFP_NOIO would make the allocations more reliable.

    Andrea
    -
    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:27    [W:0.024 / U:0.956 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site