lkml.org 
[lkml]   [2009]   [Mar]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [patch -mm] cpusets: add memory_slab_hardwall flag
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.

This requirement was mandated during the first review of the patch by
Christoph, who requested that it be configurable. Before that it was
possible to simply check if the global `number_of_cpusets' count was > 1.
If not, cpuset_node_allowed_hardwall() would always return true. If the
system had more than one cpuset, it would have reduced to checking

return in_interrupt() || (gfp_mask & __GFP_THISNODE) ||
node_isset(node, current->mems_allowed);

As I already mentioned, if fastpath optimization is your only concern,
that we could simply add PF_SLAB_HARDWALL task flags that would simply
make this

return current->flags & PF_SLAB_HARDWALL;

So the fastpath cost can be mitigated at the expense of an additional task
flag.


\
 
 \ /
  Last update: 2009-03-10 03:05    [W:0.074 / U:0.356 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site