From: Paul Jackson <pj@sgi.com>
To: Andi Kleen <ak@suse.de>
Cc: akpm@osdl.org, Simon.Derr@bull.net, linux-kernel@vger.kernel.org,
nickpiggin@yahoo.com.au, haveblue@us.ibm.com, mingo@elte.hu,
clameter@sgi.com
Subject: Re: [PATCH] Cpuset: alloc_pages_node overrides cpuset constraints
Date: Wed, 22 Mar 2006 10:05:56 -0800 [thread overview]
Message-ID: <20060322100556.8e2010a6.pj@sgi.com> (raw)
In-Reply-To: <200603221733.51726.ak@suse.de>
Andi wrote:
> Faster would be if (gfp_mask & (__GFP_NOCPUSET|__GFP_HARDWALL)) { /* sort them out */ }
Yup - good point. However ...
Note that I am already off the fast path here, having peeled off the
interrupt and node inside cpuset cases above. After these checks for
__GFP_NOCPUSET or __GFP_HARDWALL, only the rare case of having to
look outside a cpuset with no free memory for essential kernel memory
remains.
Look at this entire routine:
int __cpuset_zone_allowed(struct zone *z, gfp_t gfp_mask)
{
int node; /* node that zone z is on */
const struct cpuset *cs; /* current cpuset ancestors */
int allowed; /* is allocation in zone z allowed? */
if (in_interrupt())
return 1;
node = z->zone_pgdat->node_id;
if (node_isset(node, current->mems_allowed))
return 1;
if (gfp_mask & __GFP_NOCPUSET)
return 1;
if (gfp_mask & __GFP_HARDWALL) /* If hardwall request, stop here */
return 0;
if (current->flags & PF_EXITING) /* Let dying task have memory */
return 1;
/* Not hardwall and node outside mems_allowed: scan up cpusets */
mutex_lock(&callback_mutex);
task_lock(current);
cs = nearest_exclusive_ancestor(current->cpuset);
task_unlock(current);
allowed = node_isset(node, cs->mems_allowed);
mutex_unlock(&callback_mutex);
return allowed;
}
Notice that if neither of the __GFP_NOCPUSET or __GFP_HARDWALL flag
tests fire, then the code hits a mutex, spinlock and subroutine call.
Also notice that the __GFP_NOCPUSET case is the most important case of
those at or below that check. Any alloc_pages_node, zmalloc_node or
kmalloc_node call that requires a node outside the cpuset hits that
case. Only tasks that have used up all the available memory in their
cpuset commonly get past here, to the __GFP_HARDWALL case, which is not
a case worth optimizing at the expense of more important code paths.
So ... actually ... I suspect that doing:
if (gfp_mask & __GFP_NOCPUSET)
return 1;
if (gfp_mask & __GFP_HARDWALL)
return 0;
is faster than doing:
if (gfp_mask & (__GFP_NOCPUSET|__GFP_HARDWALL)) {
if (gfp_mask & __GFP_NOCPUSET)
return 1;
if (gfp_mask & __GFP_HARDWALL)
return 0;
}
because the first of these two gets to the relatively more important
case of __GFP_NOCPUSET faster.
Too bad the patch didn't show a little more context.
--
I won't rest till it's the best ...
Programmer, Linux Scalability
Paul Jackson <pj@sgi.com> 1.925.600.0401
prev parent reply other threads:[~2006-03-22 18:06 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-03-18 20:40 [PATCH] Cpuset: alloc_pages_node overrides cpuset constraints Paul Jackson
2006-03-20 7:07 ` Andrew Morton
2006-03-20 8:30 ` Paul Jackson
2006-03-20 15:34 ` Christoph Lameter
2006-03-22 16:33 ` Andi Kleen
2006-03-22 18:05 ` Paul Jackson [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20060322100556.8e2010a6.pj@sgi.com \
--to=pj@sgi.com \
--cc=Simon.Derr@bull.net \
--cc=ak@suse.de \
--cc=akpm@osdl.org \
--cc=clameter@sgi.com \
--cc=haveblue@us.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=nickpiggin@yahoo.com.au \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.