linux-kernel - Re: Memory management woes - order 1 allocation failures

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Fri, 12 Mar 2010 04:32:03 +0100
From:	Frans Pop <elendil@...net.nl>
To:	Mel Gorman <mel@....ul.ie>
Cc:	Greg KH <gregkh@...e.de>,
	KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>,
	Pekka Enberg <penberg@...helsinki.fi>,
	Christoph Lameter <cl@...ux-foundation.org>,
	linux-kernel@...r.kernel.org, linux-mm@...ck.org,
	Alan Cox <alan@...rguk.ukuu.org.uk>
Subject: Re: 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 
times.

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 
situations?

Cheers,
FJP

> 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.
>
> [mel@....ul.ie: Adjust TTY_BUFFER_PAGE to take padding into account]
> Signed-off-by: Alan Cox <alan@...ux.intel.com>
> Signed-off-by: Greg Kroah-Hartman <gregkh@...e.de>

Tested-by: Frans Pop <fjp@...net.nl>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/