linux-kernel - Re: [patch 00/41] cpu alloc / cpu ops v3: Optimize per cpu access

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]

Message-Id: <20080529222143.5d7aa1e5.akpm@linux-foundation.org>
Date:	Thu, 29 May 2008 22:21:43 -0700
From:	Andrew Morton <akpm@...ux-foundation.org>
To:	Christoph Lameter <clameter@....com>
Cc:	linux-arch@...r.kernel.org, linux-kernel@...r.kernel.org,
	David Miller <davem@...emloft.net>,
	Eric Dumazet <dada1@...mosbay.com>,
	Peter Zijlstra <peterz@...radead.org>,
	Rusty Russell <rusty@...tcorp.com.au>,
	Mike Travis <travis@....com>
Subject: Re: [patch 00/41] cpu alloc / cpu ops v3: Optimize per cpu access

On Thu, 29 May 2008 22:03:14 -0700 (PDT) Christoph Lameter <clameter@....com> wrote:

> On Thu, 29 May 2008, Andrew Morton wrote:
> 
> > All seems reasonable to me.  The obvious question is "how do we size
> > the arena".  We either waste memory or, much worse, run out.
> 
> The per cpu memory use by subsystems is typically quite small. We already 
> have an 8k limitation for percpu space for modules. And that does not seem 
> to be a problem.

eh?  That's DEFINE_PERCPU memory, not alloc_pecpu() memory?

> > And running out is a real possibility, I think.  Most people will only
> > mount a handful of XFS filesystems.  But some customer will come along
> > who wants to mount 5,000, and distributors will need to cater for that,
> > but how can they?
> 
> Typically these are fairly small 8 bytes * 5000 is only 20k.

It was just an example.  There will be others.

	tcp_v4_md5_do_add
	->tcp_alloc_md5sig_pool
	  ->__tcp_alloc_md5sig_pool

does an alloc_percpu for each md5-capable TCP connection.  I think - it
doesn't matter really, because something _could_.  And if something
_does_, we're screwed.

> > I wonder if we can arrange for the default to be overridden via a
> > kernel boot option?
> 
> We could do that yes.

Phew.

> > Another obvious question is "how much of a problem will we have with
> > internal fragmentation"?  This might be a drop-dead showstopper.
> 
> But then per cpu data is not frequently allocated and freed.

I think it is, in the TCP case.  And that's the only one I looked at.

Plus who knows what lies ahead of us?

> Going away from allocpercpu saves a lot of memory. We could make this 
> 128k or so to be safe?

("alloc_percpu" - please be careful about getting this stuff right)

I don't think there is presently any upper limit on alloc_percpu()?  It
uses kmalloc() and kmalloc_node()?

Even if there is some limit, is it an unfixable one?
--
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/