Re: [PATCH] Cpuset: rcu optimization of page alloc hook

[Paul Jackson <pj@sgi.com>]

> Thanks. But i guess it would be still a good idea to turn
> ia "check that there is no cpuset" test into an inline
> so that it can be done without a function call. 

Do you mean this check, in cpuset_update_task_memory_state()

        if (unlikely(!cs))
                return;

Inlining this check will -not- help systems not using cpusets.

Unlike mempolicies, which use NULL for the default case, tasks
almost always have non-NULL cpuset pointers (on any system with
CONFIG_CPUSET).

This unlikely check was here because during the early boot process,
there was a window during which the memory subsystem was healthy
enough to take calls, but the cpuset system was not initialized yet.

I can remove the above check entirely, by adding a "cpuset_init_early",
that fabricates enough of a valid cpuset for that init task to get
through this code without stumbling.

Yes - that works - patch forthcoming soon to remove the above check,
using a cpuset_init_early() call instead.

===

I have a different scheme in place to minimize the load on systems
with CONFIG_CPUSET enabled.  See the number_of_cpusets global kernel
counter, in the *-mm patch:

  cpuset_number_of_cpusets_optimization

It enables short circuiting with inline code the other key routine
on the memory allocation path: cpuset_zone_allowed().

However, looking at it just now, I realize that this number_of_cpusets
hack doesn't help with cpuset_update_task_memory_state().  Even though
the currently running system has only one cpuset, it might have had
more in the past, and some task that hasn't had to allocate memory
since the system went back down to one cpuset might still be pointing
at the old cpuset it had.

I'm still looking for a clean way to short circuit this call to
cpuset_update_task_memory_state() in the case that a system is compiled
with CONFIG_CPUSET, but no one has used cpusets.

Any other ideas?

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