lkml.org 
[lkml]   [2011]   [Apr]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: Regression from 2.6.36
    On Wed, 13 Apr 2011 14:44:16 -0700 (PDT)
    David Rientjes <rientjes@google.com> wrote:

    > > -static inline void *alloc_fdmem(unsigned int size)
    > > +static void *alloc_fdmem(unsigned int size)
    > > {
    > > - void *data;
    > > -
    > > - data = kmalloc(size, GFP_KERNEL|__GFP_NOWARN);
    > > - if (data != NULL)
    > > - return data;
    > > -
    > > + /*
    > > + * Very large allocations can stress page reclaim, so fall back to
    > > + * vmalloc() if the allocation size will be considered "large" by the VM.
    > > + */
    > > + if (size <= (PAGE_SIZE << PAGE_ALLOC_COSTLY_ORDER) {
    > > + void *data = kmalloc(size, GFP_KERNEL|__GFP_NOWARN);
    > > + if (data != NULL)
    > > + return data;
    > > + }
    > > return vmalloc(size);
    > > }
    > >
    >
    > It's a shame that we can't at least try kmalloc() with sufficiently large
    > sizes by doing something like
    >
    > gfp_t flags = GFP_NOWAIT | __GFP_NOWARN;
    >
    > if (size <= (PAGE_SIZE << PAGE_ALLOC_COSTLY_ORDER))
    > flags |= GFP_KERNEL;
    > data = kmalloc(size, flags);
    > if (data)
    > return data;
    > return vmalloc(size);
    >
    > which would at least attempt to use the slab allocator.

    Maybe. If the fdtable is that huge then the fork() is probably going
    to be pretty slow anyway. And the large allocation might cause
    depletion of high-order free pages and might cause fragmentation of
    even-higher-order pages by splitting them up. </handwaving>


    \
     
     \ /
      Last update: 2011-04-13 23:57    [W:4.019 / U:6.084 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site