Messages in this thread | | | Subject | Re: [patch -mm] cpusets: add memory_slab_hardwall flag | From | Matt Mackall <> | Date | Mon, 09 Mar 2009 23:05:54 -0500 |
| |
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
| |