[lkml]   [2008]   [May]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [patch 00/41] cpu alloc / cpu ops v3: Optimize per cpu access
On Thu, 29 May 2008, Andrew Morton wrote:

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

No. The module subsystem has its own alloc_percpu subsystem that the
cpu_alloc replaces.

> > We could do that yes.
> Phew.

But its going to be even more complicated and I have a hard time managing
the complexity here. Could someone take pieces off my hand?

> > 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.

Which tcp case?

> Plus who knows what lies ahead of us?

Well invariably we will end up with cpu area defragmentation.... Sigh.

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

No there is no limit. It just wastes lots of space (pointer arrays,
alignment etc) that we could use to configure sufficiently large per cpu

 \ /
  Last update: 2008-05-30 07:31    [W:0.165 / U:2.940 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site