From: Rohit Seth <rohit.seth@intel.com>
To: Christoph Lameter <clameter@engr.sgi.com>
Cc: akpm@osdl.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH]: Clean up of __alloc_pages
Date: Mon, 03 Oct 2005 09:55:58 -0700 [thread overview]
Message-ID: <1128358558.8472.13.camel@akash.sc.intel.com> (raw)
In-Reply-To: <Pine.LNX.4.62.0510030828400.7812@schroedinger.engr.sgi.com>
On Mon, 2005-10-03 at 08:34 -0700, Christoph Lameter wrote:
> On Sat, 1 Oct 2005, Seth, Rohit wrote:
>
> > - goto zone_reclaim_retry;
> > - }
> > + if (order == 0) {
> > + for (i = 0; (z = zones[i]) != NULL; i++) {
> > + page = buffered_rmqueue(z, 0, gfp_mask, 0);
> > + if (page)
> > + goto got_pg;
> > }
> > -
>
> This is checking all zones for pages on the pcp before going the more
> expensive route?
>
That is right.
> Seems that this removes the logic intended to prefer local
> allocations over remote pages present in the existing alloc_pages? There
> is the danger that this modification will lead to the allocation of remote
> pages even if local pages are available. Thus reducing performance.
>
Good catch. I will up level the cpuset check in buffered_rmqueue rather
then doing it in get_page_from_freelist. That should retain the current
preferences for local pages.
> I would suggest to just check the first zone's pcp instead of all zones.
>
Na. This for most cases will be ZONE_DMA pcp list having nothing much
most of the time. And picking any other zone randomly will be exposed
to faulty behavior.
Thanks,
-rohit
WARNING: multiple messages have this Message-ID (diff)
From: Rohit Seth <rohit.seth@intel.com>
To: Christoph Lameter <clameter@engr.sgi.com>
Cc: akpm@osdl.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH]: Clean up of __alloc_pages
Date: Mon, 03 Oct 2005 09:55:58 -0700 [thread overview]
Message-ID: <1128358558.8472.13.camel@akash.sc.intel.com> (raw)
In-Reply-To: <Pine.LNX.4.62.0510030828400.7812@schroedinger.engr.sgi.com>
On Mon, 2005-10-03 at 08:34 -0700, Christoph Lameter wrote:
> On Sat, 1 Oct 2005, Seth, Rohit wrote:
>
> > - goto zone_reclaim_retry;
> > - }
> > + if (order == 0) {
> > + for (i = 0; (z = zones[i]) != NULL; i++) {
> > + page = buffered_rmqueue(z, 0, gfp_mask, 0);
> > + if (page)
> > + goto got_pg;
> > }
> > -
>
> This is checking all zones for pages on the pcp before going the more
> expensive route?
>
That is right.
> Seems that this removes the logic intended to prefer local
> allocations over remote pages present in the existing alloc_pages? There
> is the danger that this modification will lead to the allocation of remote
> pages even if local pages are available. Thus reducing performance.
>
Good catch. I will up level the cpuset check in buffered_rmqueue rather
then doing it in get_page_from_freelist. That should retain the current
preferences for local pages.
> I would suggest to just check the first zone's pcp instead of all zones.
>
Na. This for most cases will be ZONE_DMA pcp list having nothing much
most of the time. And picking any other zone randomly will be exposed
to faulty behavior.
Thanks,
-rohit
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2005-10-03 16:48 UTC|newest]
Thread overview: 90+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-10-01 19:00 [PATCH]: Clean up of __alloc_pages Seth, Rohit
2005-10-01 19:00 ` Seth, Rohit
2005-10-02 3:09 ` Nick Piggin
2005-10-02 3:09 ` Nick Piggin
2005-10-03 16:50 ` Rohit Seth
2005-10-03 16:50 ` Rohit Seth
2005-10-03 15:34 ` Christoph Lameter
2005-10-03 15:34 ` Christoph Lameter
2005-10-03 16:55 ` Rohit Seth [this message]
2005-10-03 16:55 ` Rohit Seth
2005-10-03 16:57 ` Christoph Lameter
2005-10-03 16:57 ` Christoph Lameter
2005-10-03 17:48 ` Rohit Seth
2005-10-03 17:48 ` Rohit Seth
2005-10-04 13:27 ` Andi Kleen
2005-10-04 13:27 ` Andi Kleen
2005-10-04 16:26 ` Ray Bryant
2005-10-04 16:26 ` Ray Bryant
2005-10-04 16:10 ` Martin J. Bligh
2005-10-04 16:10 ` Martin J. Bligh
2005-10-04 17:02 ` Ray Bryant
2005-10-04 17:02 ` Ray Bryant
-- strict thread matches above, loose matches on Subject: below --
2005-10-29 1:33 Rohit, Seth
2005-10-29 1:33 ` Rohit, Seth
2005-10-29 2:33 ` Nick Piggin
2005-10-29 2:33 ` Nick Piggin
2005-10-31 20:55 ` Rohit Seth
2005-10-31 20:55 ` Rohit Seth
2005-11-01 1:14 ` Nick Piggin
2005-11-01 1:14 ` Nick Piggin
2005-11-04 18:15 ` Rohit Seth
2005-11-04 18:15 ` Rohit Seth
2005-11-05 0:00 ` Nick Piggin
2005-11-05 0:00 ` Nick Piggin
2005-10-30 0:16 ` Paul Jackson
2005-10-30 0:16 ` Paul Jackson
2005-10-31 19:09 ` Rohit Seth
2005-10-31 19:09 ` Rohit Seth
2005-11-05 17:09 ` Andi Kleen
2005-11-05 17:09 ` Andi Kleen
2005-11-06 4:18 ` Paul Jackson
2005-11-06 4:18 ` Paul Jackson
2005-11-06 17:35 ` Andi Kleen
2005-11-06 17:35 ` Andi Kleen
2005-11-06 20:49 ` Paul Jackson
2005-11-06 20:49 ` Paul Jackson
2005-11-07 2:57 ` Nick Piggin
2005-11-07 2:57 ` Nick Piggin
2005-11-07 3:42 ` Andi Kleen
2005-11-07 3:42 ` Andi Kleen
2005-11-07 4:37 ` Paul Jackson
2005-11-07 4:37 ` Paul Jackson
2005-11-07 6:08 ` Nick Piggin
2005-11-07 6:08 ` Nick Piggin
2005-11-07 9:46 ` Paul Jackson
2005-11-07 9:46 ` Paul Jackson
2005-11-07 10:17 ` Nick Piggin
2005-11-07 10:17 ` Nick Piggin
2005-11-07 14:41 ` Paul Jackson
2005-11-07 14:41 ` Paul Jackson
2005-11-07 3:44 ` Paul Jackson
2005-11-07 3:44 ` Paul Jackson
2005-10-30 1:47 ` Paul Jackson
2005-10-30 1:47 ` Paul Jackson
2005-10-30 2:01 ` Nick Piggin
2005-10-30 2:01 ` Nick Piggin
2005-10-30 2:19 ` Paul Jackson
2005-10-30 2:19 ` Paul Jackson
2005-10-30 2:32 ` Nick Piggin
2005-10-30 2:32 ` Nick Piggin
2005-10-30 3:06 ` Paul Jackson
2005-10-30 3:06 ` Paul Jackson
2005-10-30 3:53 ` Nick Piggin
2005-10-30 3:53 ` Nick Piggin
2005-10-30 2:26 ` Paul Jackson
2005-10-30 2:26 ` Paul Jackson
2005-10-30 2:36 ` Nick Piggin
2005-10-30 2:36 ` Nick Piggin
2005-10-30 3:09 ` Paul Jackson
2005-10-30 3:09 ` Paul Jackson
2005-10-30 3:55 ` Nick Piggin
2005-10-30 3:55 ` Nick Piggin
2005-10-30 4:11 ` Paul Jackson
2005-10-30 4:11 ` Paul Jackson
2005-10-31 21:20 ` Rohit Seth
2005-10-31 21:20 ` Rohit Seth
2005-10-31 21:28 ` Paul Jackson
2005-10-31 21:28 ` Paul Jackson
2005-11-05 1:57 Seth, Rohit
2005-11-05 1:57 ` Seth, Rohit
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=1128358558.8472.13.camel@akash.sc.intel.com \
--to=rohit.seth@intel.com \
--cc=akpm@osdl.org \
--cc=clameter@engr.sgi.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
/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.