Re: A solution for more GFP_xx flags?

[Paul Jackson <pj@sgi.com>]

> struct allocation_control {
> 	unsigned long flags;	/* Traditional flags */
> 	int node;
> 	struct cpuset_context *cpuset;

I don't understand what purpose this cpuset pointer has.

The main (heavily traveled) code paths beneath __alloc_pages() don't
look at the tasks cpuset at all, and the less traveled code paths only
look at the current tasks cpuset.

I have no clue how the above cpuset pointer could (usefully) be
anything other than just a copy of current->cpuset.  Also, without
serious reworking of the locking and likely some performance impact, I
have no idea what use this cpuset pointer would be on the main memory
allocation code paths.

The cpuset imposed constraints on an allocation are represented by the
mems_allowed nodemask and the flags PF_SPREAD_PAGE and PF_SPREAD_SLAB
in the task struct.  If the memory constraints imposed by a tasks
cpuset change, then these constraints are transfered to the tasks
mems_allowed and flags by the routine cpuset_update_task_memory_state().

Unlike mm/mempolicy.c NUMA mempolicies, one task -can- change the cpuset
of another task.  This forces us to have fancier (more expensive)
locking on cpusets, and that means we have to keep cpusets off the hot
memory allocation code paths and instead cache their constraints in the
task struct.

-- 
                  I won't rest till it's the best ...
                  Programmer, Linux Scalability
                  Paul Jackson <pj@sgi.com> 1.925.600.0401

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>