Re: [patch -mm] cpusets: add memory_slab_hardwall flag

From: Matt Mackall
Date: Tue Mar 10 2009 - 00:11:54 EST


On Mon, 2009-03-09 at 19:01 -0700, David Rientjes wrote:
> On Tue, 10 Mar 2009, KOSAKI Motohiro wrote:
>
> > That's pointless.
> > Again, any fastpath modification should have reasonable reason.
> > We are looking for your explanation.
> >
>
> The fastpath modification simply checks if the hardwall bit is set in the
> allocating task's cpuset flags. If it's disabled, there is no additional
> overhead.

Ok, I for one understand perfectly the desire for this feature.

But we are still extremely sensitive to adding potential branches to one
of the most important fast-paths in the kernel, especially for a feature
with a fairly narrow use case. We've invested an awful lot of time into
micro-optimizing SLAB (by rewriting it as SLUB/SLQB) so any steps
backward at this stage are cause for concern. Also, remember 99%+ of
users will never care about this feature.

For SLOB, I think the code is fine as it stands, but we probably want to
be a bit more clever for the others. At the very minimum, we'd like this
to be in an unlikely path. Better still if the initial test can somehow
be hidden with another test. It might also be possible to use the
patching code used by markers to enable the path only when one or more
tasks needs it.

--
http://selenic.com : development and support for Mercurial and Linux


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/