lkml.org 
[lkml]   [2011]   [Apr]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: Regression from 2.6.36
    From
    Date
    Le mardi 12 avril 2011 à 18:31 -0700, Andrew Morton a écrit :
    > On Wed, 13 Apr 2011 09:23:11 +0800 Changli Gao <xiaosuo@gmail.com> wrote:
    >
    > > On Wed, Apr 13, 2011 at 6:49 AM, Andrew Morton
    > > <akpm@linux-foundation.org> wrote:
    > > >
    > > > It's somewhat unclear (to me) what caused this regression.
    > > >
    > > > Is it because the kernel is now doing large kmalloc()s for the fdtable,
    > > > and this makes the page allocator go nuts trying to satisfy high-order
    > > > page allocation requests?
    > > >
    > > > Is it because the kernel now will usually free the fdtable
    > > > synchronously within the rcu callback, rather than deferring this to a
    > > > workqueue?
    > > >
    > > > The latter seems unlikely, so I'm thinking this was a case of
    > > > high-order-allocations-considered-harmful?
    > > >
    > >
    > > Maybe, but I am not sure. Maybe my patch causes too many inner
    > > fragments. For example, when asking for 5 pages, get 8 pages, and 3
    > > pages are wasted, then memory thrash happens finally.
    >
    > That theory sounds less likely, but could be tested by using
    > alloc_pages_exact().
    >

    Very unlikely, since fdtable sizes are powers of two, unless you hit
    sysctl_nr_open and it was changed (default value being 2^20)




    --
    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: 2011-04-13 04:39    [W:4.054 / U:0.028 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site