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] [thread-next>] [day] [month] [year] [list]
Date:	Thu, 26 Sep 2013 14:58:22 -0700
From:	Andrew Morton <akpm@...ux-foundation.org>
To:	Peter Hurley <peter@...leysoftware.com>
Cc:	Greg KH <gregkh@...uxfoundation.org>,
	Fengguang Wu <fengguang.wu@...el.com>,
	LKML <linux-kernel@...r.kernel.org>, lkp@...org,
	Tejun Heo <tj@...nel.org>
Subject: Re: increased vmap_area_lock contentions on
 "n_tty: Move buffers into n_tty_data"

On Thu, 26 Sep 2013 17:42:52 -0400 Peter Hurley <peter@...leysoftware.com> wrote:

> On 09/26/2013 02:05 PM, Andrew Morton wrote:
> > On Thu, 26 Sep 2013 13:35:32 -0400 Peter Hurley <peter@...leysoftware.com> wrote:
> >
> >> The issue with a single large kmalloc is that it may fail where
> >> 3 separate, page-or-less kmallocs would not have.
> >
> > Or vmalloc fails first, because of internal fragmentation of the vmap
> > arena.  This problem plus vmalloc's slowness are the reasons why
> > vmalloc should be avoided.
> 
> Ok, no vmalloc.
> 
> > A tremendous number of places in the kernel perform higher-order
> > allocations nowadays.  The page allocator works damn hard to service
> > them and I expect that switching to kmalloc here will be OK.
> 
> I've had order-4 allocation failures before on 10Gb.

Yep.  But this allocation will be order=2, yes?  And
PAGE_ALLOC_COSTLY_ORDER=3.  So if that thing is working correctly,
order=2 will do a lot better than order=4.

> In fact, the
> nouveau driver switched to vmalloc for that very reason (commit
> d005f51eb93d71cd40ebd11dd377453fa8c8a42a, drm/nouveau: use vmalloc
> for pgt allocation).

Sigh.  I'm not aware of any reports of anyone hitting arena
fragmentation problems yet, so it remains a theoretical thing.  But the
more we use vmalloc, the more likely it becomes.  And because the usage
sites are so disparate, fixing it will be pretty horrid.

For this reason (plus vmalloc is slow), I do think it's better to do
the old

	foo = kmalloc(__GFP_NOWARN);
	if (!foo)
		foo = vmalloc();

thing.  It's ugly, but will greatly reduce the amount of vmallocing
which happens.

Someone had a patch a while back which wraps this operation (and the
corresponding free) into library functions.  I said yuk and it wasn't
merged.  Perhaps that was a mistake.
--
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/

Powered by blists - more mailing lists