Re: [PATCH 3/6] cpuset write throttle

[Paul Jackson <pj@sgi.com>]

Peter wrote:
> Ugh, yeah. Its a statistical thing, but task_lock is quite a big lock to
> take. Are cpusets RCU freed?

Yes, current->cpuset is rcu freed.  And on the one hottest code path
that wants to look inside a cpuset, once per memory page allocation,
we look inside the current tasks cpuset to see if it has been modified
since last we looked (if it has, we go into slow path code to update
the current->mems_allowed nodemask.)   The code that does this, from
kernel/cpuset.c, is:

	rcu_read_lock();
	my_cpusets_mem_gen = task_cs(current)->mems_generation;
	rcu_read_unlock();

Sadly, I just noticed now, that with the new cgroup (aka container)
code in *-mm (and soon to be in 2.6.24), that 'task_cs' macro got
added, to deal with the fact that what used to be a single pointer in
the task struct directly to the tasks cpuset is now perhaps two more
dereferences and a second, buried, rcu guarded access away:

static inline struct cpuset *task_cs(struct task_struct *task)
{
        return container_of(task_subsys_state(task, cpuset_subsys_id),
                            struct cpuset, css);
}

static inline struct cgroup_subsys_state *task_subsys_state(
        struct task_struct *task, int subsys_id)
{
        return rcu_dereference(task->cgroups->subsys[subsys_id]);
}

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