Re: [RFC][PATCH] "challenged" memory controller

[Balbir Singh <balbir@in.ibm.com>]

Paul Jackson wrote:
> Dave wrote:
>> I've been toying with a little memory controller for the past
>> few weeks, on and off.
> 
> I haven't actually thought about this much yet, but I suspect:
> 
>  1) This is missing some cpuset locking - look at the routine
>     kernel/cpuset.c:__cpuset_memory_pressure_bump() for the
>     locking required to reference current->cpuset, using task_lock().
>     Notice that the current->cpuset reference is not valid once
>     the task lock is dropped.
> 
>  2) This might not scale well, with a hot spot in the cpuset.  So
>     far, I avoid any reference to the cpuset structure on hot code
>     paths, especially any write references, but even read references,
>     due to the above need for the task lock.

Would it be possible to protect task->cpuset using rcu_read_lock() for read 
references as cpuset_update_task_memory_state() does (and use the generations 
trick to see if a task changed cpusets)? I guess the cost paid is an additional 
field in the page structure to add generations.

-- 

	Balbir Singh,
	Linux Technology Center,
	IBM Software Labs

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