Messages in this thread | | | Date | Sat, 11 Sep 2004 22:35:05 -0700 | From | Paul Jackson <> | Subject | Re: [Patch 4/4] cpusets top mask just online, not all possible |
| |
Dave wrote: > Is it easy to tell if a given page was influenced by a cpusets > allocation? How would the memory removal code know which task[s] to go > and update?
It is not nearly as easy as for cpus to know which tasks to update, because cpus have a list of tasks on them.
And it is not nearly as easy as for cpus to _do_ the update, because a tasks memory placement, unlike its cpu placement, can not be changed by a third party. So one has to leave a hint laying in wait for the task to be changed, which the task can trip over and use to trigger its own memory placement update. Grep for 'generation' in kernel/cpuset.c for the cpuset version of this hint.
We will need two pieces:
1) We will need some user space code, that walks through all cpusets, and for each cpuset that includes the node in question, updates that cpuset to not have that node (which will bump that cpusets generation).
2) Then each task that is attached to that cpuset, the next time that task is about to ask for memory (in one of the mm/mempolicy routines, just before entering __alloc_pages()) will notice the generation number on its cpuset has changed, and the cpuset_update_current_mems_allowed() code will update the tasks mems_allowed to the correct, online, value.
With what I expect to submit to lkml for *-mm in a few hours, piece (2) will be complete and ready to go. Piece (1) can wait.
> We'll fix it when we get there :)
Yup.
-- I won't rest till it's the best ... Programmer, Linux Scalability Paul Jackson <pj@sgi.com> 1.650.933.1373 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |