lkml.org 
[lkml]   [2009]   [Mar]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [patch -mm v2] cpusets: add memory_slab_hardwall flag
On Mon, 9 Mar 2009, David Rientjes wrote:

> This interface is lockless and very quick in the slab allocator fastpath
> when not enabled because a new task flag, PF_SLAB_HARDWALL, is added to
> determine whether or not its cpuset has mandated objects be allocated on
> the set of allowed nodes. If the option is not set for a task's cpuset
> (or only a single cpuset exists), this reduces to only checking for a
> specific bit in current->flags.

We already have PF_SPREAD_PAGE PF_SPREAD_SLAB and PF_MEMPOLICY.
PF_MEMPOLICY in slab can have the same role as PF_SLAB_HARDWALL. It
attempts what you describe. One the one hand you duplicate functionality
that is already there and on the other you want to put code in the hot
paths that we have intentionally avoided for ages.

The description is not accurate. This feature is only useful if someone
comes up with a crummy cpuset definition in which a processor is a member
of multiple cpusets and thus the per cpu queues of multiple subsystems get
objects depending on which cpuset is active.

If a processor is only used from one cpuset (natural use) then these
problems do not occur.

There is still no use case for this on a NUMA platform. NUMA jobs that I
know about where people care about latencies have cpusets that do not
share processors and thus this problem does not occur.



\
 
 \ /
  Last update: 2009-03-10 22:13    [W:0.068 / U:0.540 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site