linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Andrew Morton <akpm@linux-foundation.org>
To: Eric Dumazet <eric.dumazet@gmail.com>
Cc: "Changli Gao" <xiaosuo@gmail.com>,
	"Américo Wang" <xiyou.wangcong@gmail.com>,
	"Jiri Slaby" <jslaby@suse.cz>, azurIt <azurit@pobox.sk>,
	linux-kernel@vger.kernel.org, linux-mm@kvack.org,
	linux-fsdevel@vger.kernel.org, "Jiri Slaby" <jirislaby@gmail.com>
Subject: Re: Regression from 2.6.36
Date: Tue, 12 Apr 2011 15:49:06 -0700	[thread overview]
Message-ID: <20110412154906.70829d60.akpm@linux-foundation.org> (raw)
In-Reply-To: <1302190586.3357.45.camel@edumazet-laptop>

On Thu, 07 Apr 2011 17:36:26 +0200
Eric Dumazet <eric.dumazet@gmail.com> wrote:

> Le jeudi 07 avril 2011 __ 23:27 +0800, Changli Gao a __crit :
> 
> > azurlt, would you please test the patch attached? Thanks.
> > 
> 
> Yes of course, I meant to reverse the patch
> 
> (use kmalloc() under PAGE_SIZE, vmalloc() for 'big' allocs)
> 
> 
> Dont fallback to vmalloc if kmalloc() fails.
> 
> 
> if (size <= PAGE_SIZE)
> 	return kmalloc(size, GFP_KERNEL);
> else
> 	return vmalloc(size);
> 

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?


  reply	other threads:[~2011-04-12 22:50 UTC|newest]

Thread overview: 45+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-03-15 13:25 Regression from 2.6.36 azurIt
2011-03-17  0:15 ` Greg KH
2011-03-17  0:53   ` Dave Jones
2011-03-17 13:30     ` azurIt
2011-04-07 10:01   ` azurIt
2011-04-07 10:19     ` Jiri Slaby
2011-04-07 11:21       ` Américo Wang
2011-04-07 11:57         ` Eric Dumazet
2011-04-07 12:13           ` Eric Dumazet
2011-04-07 15:27             ` Changli Gao
2011-04-07 15:36               ` Eric Dumazet
2011-04-12 22:49                 ` Andrew Morton [this message]
2011-04-13  1:23                   ` Changli Gao
2011-04-13  1:31                     ` Andrew Morton
2011-04-13  2:37                       ` Eric Dumazet
2011-04-13  6:54                         ` Regarding memory fragmentation using malloc Pintu Agarwal
2011-04-13 11:44                           ` Américo Wang
2011-04-13 13:56                             ` Pintu Agarwal
2011-04-13 15:25                               ` Michal Nazarewicz
2011-04-14  6:44                                 ` Pintu Agarwal
2011-04-14 10:47                                   ` Michal Nazarewicz
2011-04-14 12:24                                     ` Pintu Agarwal
2011-04-14 12:31                                       ` Michal Nazarewicz
2011-04-13 21:16                         ` Regression from 2.6.36 Andrew Morton
2011-04-13 21:24                           ` Andrew Morton
2011-04-19 19:29                             ` azurIt
2011-04-19 19:55                               ` Andrew Morton
2011-04-13 21:44                           ` David Rientjes
2011-04-13 21:54                             ` Andrew Morton
2011-04-14  2:10                           ` Eric Dumazet
2011-04-14  5:28                             ` Andrew Morton
2011-04-14  6:31                               ` Eric Dumazet
2011-04-14  9:08                                 ` azurIt
2011-04-14 10:27                                   ` Eric Dumazet
2011-04-14 10:31                                     ` azurIt
2011-04-14 10:25                           ` Mel Gorman
2011-04-15  9:59                             ` azurIt
2011-04-15 10:47                               ` Mel Gorman
2011-04-15 10:56                                 ` azurIt
2011-04-15 11:17                                   ` Mel Gorman
2011-04-15 11:36                                     ` azurIt
2011-04-15 13:01                                       ` Mel Gorman
2011-04-15 13:21                                         ` azurIt
2011-04-15 14:15                                           ` Mel Gorman
2011-04-08 12:25               ` azurIt

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20110412154906.70829d60.akpm@linux-foundation.org \
    --to=akpm@linux-foundation.org \
    --cc=azurit@pobox.sk \
    --cc=eric.dumazet@gmail.com \
    --cc=jirislaby@gmail.com \
    --cc=jslaby@suse.cz \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=xiaosuo@gmail.com \
    --cc=xiyou.wangcong@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).