From: William Lee Irwin III <wli@holomorphy.com>
To: Jesse Barnes <jbarnes@engr.sgi.com>
Cc: akpm@osdl.org, linux-kernel@vger.kernel.org, steiner@sgi.com
Subject: Re: [PATCH] allocate page caches pages in round robin fasion
Date: Thu, 12 Aug 2004 17:13:31 -0700 [thread overview]
Message-ID: <20040813001331.GR11200@holomorphy.com> (raw)
In-Reply-To: <200408121646.50740.jbarnes@engr.sgi.com>
On Thu, Aug 12, 2004 at 04:46:50PM -0700, Jesse Barnes wrote:
> +struct page *alloc_page_round_robin(unsigned int gfp_mask)
> +{
> + return alloc_pages_node(__get_cpu_var(next_rr_node)++ % numnodes,
> + gfp_mask, 0);
> +}
> +
Interesting. This may attempt to allocate from offlined nodes, assuming
one adds on sufficient hotplug bits atop mainline and/or -mm. The
following almost does it hotplug-safe except that it needs to enter the
allocator with preemption disabled and drop the preempt_count
internally to it.
static struct page *alloc_page_round_robin(unsigned gfp_mask)
{
int nid, next_nid, *rr_node = &__get_cpu_var(next_rr_node);
nid = *rr_node;
next_nid = next_node(nid, node_online_map);
if (next_nid >= MAX_NR_NODES)
*rr_node = first_node(node_online_map);
else
*rr_node = next_nid;
return alloc_pages_node(nid, gfp_mask, 0);
}
I suspect we are better off punting this in the direction of hotplug
people than trying to address it ourselves. I think we should go with
this now, as the node hotplug bits are yet to hit the tree.
-- wli
next prev parent reply other threads:[~2004-08-13 0:13 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-08-12 23:46 [PATCH] allocate page caches pages in round robin fasion Jesse Barnes
2004-08-13 0:13 ` William Lee Irwin III [this message]
2004-08-13 0:25 ` Jesse Barnes
2004-08-13 0:32 ` William Lee Irwin III
2004-08-13 14:50 ` Martin J. Bligh
2004-08-13 15:59 ` Jesse Barnes
2004-08-13 16:20 ` Martin J. Bligh
2004-08-13 16:34 ` Jesse Barnes
2004-08-13 16:47 ` Martin J. Bligh
2004-08-13 17:31 ` Nick Piggin
2004-08-13 21:16 ` Martin J. Bligh
2004-08-13 22:59 ` Martin J. Bligh
2004-08-14 1:21 ` Nick Piggin
[not found] <fa.hmrqqf6.ckie1e@ifi.uio.no>
[not found] ` <fa.cg3cafa.ngi9og@ifi.uio.no>
2004-08-13 17:31 ` Ray Bryant
[not found] <fa.hmbmqn2.d4ef9c@ifi.uio.no>
[not found] ` <fa.g1i2d5e.1kgqq80@ifi.uio.no>
2004-08-13 16:33 ` Ray Bryant
[not found] <2sxuC-429-3@gated-at.bofh.it>
2004-08-13 1:14 ` Andi Kleen
2004-08-13 1:26 ` William Lee Irwin III
2004-08-13 1:29 ` Jesse Barnes
2004-08-13 16:04 ` Jesse Barnes
2004-08-13 17:31 ` Brent Casavant
2004-08-13 20:16 ` Andi Kleen
-- strict thread matches above, loose matches on Subject: below --
2004-08-12 23:38 Jesse Barnes
2004-08-13 1:36 ` Dave Hansen
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=20040813001331.GR11200@holomorphy.com \
--to=wli@holomorphy.com \
--cc=akpm@osdl.org \
--cc=jbarnes@engr.sgi.com \
--cc=linux-kernel@vger.kernel.org \
--cc=steiner@sgi.com \
/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.