[lkml]   [2010]   [Mar]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: Memory management woes - order 1 allocation failures
On Tuesday 02 March 2010, Mel Gorman wrote:
> On Tue, Mar 02, 2010 at 10:17:51PM +0000, Alan Cox wrote:
> > > -#define TTY_BUFFER_PAGE ((PAGE_SIZE - 256) / 2)
> > > +#define TTY_BUFFER_PAGE (((PAGE_SIZE - sizeof(struct tty_buffer)) /
> > > 2) & ~0xFF)
> >
> > Yes agreed I missed a '-1'
> Frans, would you mind testing your NAS box with the following patch
> applied please? It should apply cleanly on top of 2.6.33-rc7. Thanks

Thanks Mel.

I've been running with this patch for about a week now and have so far not
seen any more allocation failures. I've tried doing large rsyncs a few

It's not 100% conclusive, but I would say it improves things and I've
certainly not noticed any issues with the patch.

Before I got the patch I noticed that the default value for
vm.min_free_kbytes was only 1442 for this machine. Isn't that on the low
side? Could that have been a factor?

My concern is that, although fixing bugs in GFP_ATOMIC allocations is
certainly very good, I can't help wondering why the system does not keep a
bit more memory in reserve instead of using everything up for relatively
silly things like cache and buffers.
What if during an rsync I plug in some USB device whose driver has some
valid GFP_ATOMIC allocations? Shouldn't the memory manager allow for such


> tty: Keep the default buffering to sub-page units
> We allocate during interrupts so while our buffering is normally diced
> up small anyway on some hardware at speed we can pressure the VM
> excessively for page pairs. We don't really need big buffers to be
> linear so don't try so hard.
> In order to make this work well we will tidy up excess callers to
> request_room, which cannot itself enforce this break up.
> [ Adjust TTY_BUFFER_PAGE to take padding into account]
> Signed-off-by: Alan Cox <>
> Signed-off-by: Greg Kroah-Hartman <>

Tested-by: Frans Pop <>

 \ /
  Last update: 2010-03-12 04:35    [W:0.047 / U:0.128 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site