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

On Thu, 29 May 2008 22:27:53 -0700 (PDT) Christoph Lameter <clameter@xxxxxxx> wrote:

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.

That is to support DEFINE_PER_CPU, not alloc_percpu().

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?

It could be done later on.

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?

The one you just deleted from my reply :(

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

Christoph, please. An allocator which is of fixed size and which is
vulnerable to internal fragmentation is a huge problem! The kernel is
subject to wildly varying workloads both between different users and in
the hands of a single user.

If we were to merge all this code and then run into the problems which
I fear then we are tremendously screwed. We must examine this
exhaustively, in the most paranoid fashion.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Relevant Pages

  • Re: [patch 00/41] cpu alloc / cpu ops v3: Optimize per cpu access
    ... have an 8k limitation for percpu space for modules. ... The module subsystem has its own alloc_percpu subsystem that the ... I think it is, in the TCP case. ... Well invariably we will end up with cpu area defragmentation.... ...
    (Linux-Kernel)
  • clientdataset
    ... Does anyone know of a component to provide the ability to manipulate tables ... in memory (like ClientDataSet does). ... It is only for a single user (me - ...
    (borland.public.delphi.non-technical)
  • Re: prevent out of memory
    ... > carloschoenberg writes: ... >> evidence of what happened can be collected. ... > But the system can run out of memory without any particular process being ... running out of memory, even at the hands of a single user, without ...
    (comp.os.linux.misc)
  • Couldnt save. System is locked by User "Admin" on
    ... System is locked by User 'Admin' on ... machine 'xyz'. ... Out of memory. ... A single user is getting this message out of a group of 30 ...
    (microsoft.public.access.security)
  • prevent out of memory
    ... Is there any way to configure a system so that a single user can not ... run the system out of virtual memory? ... memory for root so that I can always ssh into the box or log in on the ... Please note that a per process limit less than available memory+swap ...
    (comp.os.linux.misc)