From: Andrew Morton <akpm@linux-foundation.org>
To: Mel Gorman <mel@csn.ul.ie>
Cc: Namhyung Kim <namhyung@gmail.com>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org,
Johannes Weiner <hannes@cmpxchg.org>
Subject: Re: [PATCH] mm: batch-free pcp list if possible
Date: Thu, 10 Feb 2011 13:00:37 -0800 [thread overview]
Message-ID: <20110210130037.24dbde41.akpm@linux-foundation.org> (raw)
In-Reply-To: <20110210093544.GA17873@csn.ul.ie>
On Thu, 10 Feb 2011 09:35:44 +0000
Mel Gorman <mel@csn.ul.ie> wrote:
> > What's the point in that? What relationship does the number of
> > contiguous empty lists have with the number of pages to free from one
> > list?
> >
>
> The point is to avoid excessive checking of empty lists.
It seems pretty simple to me to skip the testing of empty lists
altogether. I suggested one way, however I suspect a better approach
might be to maintain a count of the number of pages in each list and
then change free_pcppages_bulk() so that it calculates up-front the
number of pages to free from each list (equal proportion of each) then
sits in a tight loop freeing that number of pages.
It might be that the overhead of maintaining the per-list count makes
that not worthwhile. It'll be hard to tell because the count
maintenance cost will be smeared all over the place.
I doubt if any of it matters much, compared to the cost of allocating,
populating and freeing a page. I just want free_pcppages_bulk() to
stop hurting my brain ;)
WARNING: multiple messages have this Message-ID (diff)
From: Andrew Morton <akpm@linux-foundation.org>
To: Mel Gorman <mel@csn.ul.ie>
Cc: Namhyung Kim <namhyung@gmail.com>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org,
Johannes Weiner <hannes@cmpxchg.org>
Subject: Re: [PATCH] mm: batch-free pcp list if possible
Date: Thu, 10 Feb 2011 13:00:37 -0800 [thread overview]
Message-ID: <20110210130037.24dbde41.akpm@linux-foundation.org> (raw)
In-Reply-To: <20110210093544.GA17873@csn.ul.ie>
On Thu, 10 Feb 2011 09:35:44 +0000
Mel Gorman <mel@csn.ul.ie> wrote:
> > What's the point in that? What relationship does the number of
> > contiguous empty lists have with the number of pages to free from one
> > list?
> >
>
> The point is to avoid excessive checking of empty lists.
It seems pretty simple to me to skip the testing of empty lists
altogether. I suggested one way, however I suspect a better approach
might be to maintain a count of the number of pages in each list and
then change free_pcppages_bulk() so that it calculates up-front the
number of pages to free from each list (equal proportion of each) then
sits in a tight loop freeing that number of pages.
It might be that the overhead of maintaining the per-list count makes
that not worthwhile. It'll be hard to tell because the count
maintenance cost will be smeared all over the place.
I doubt if any of it matters much, compared to the cost of allocating,
populating and freeing a page. I just want free_pcppages_bulk() to
stop hurting my brain ;)
--
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/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2011-02-10 21:01 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-02-09 13:21 [PATCH] mm: batch-free pcp list if possible Namhyung Kim
2011-02-09 13:21 ` Namhyung Kim
2011-02-09 14:41 ` Johannes Weiner
2011-02-09 14:41 ` Johannes Weiner
2011-02-09 20:38 ` Andrew Morton
2011-02-09 20:38 ` Andrew Morton
2011-02-09 21:33 ` Johannes Weiner
2011-02-09 21:33 ` Johannes Weiner
2011-02-09 21:47 ` Andrew Morton
2011-02-09 21:47 ` Andrew Morton
2011-02-09 23:23 ` Minchan Kim
2011-02-09 23:23 ` Minchan Kim
2011-02-10 9:35 ` Mel Gorman
2011-02-10 9:35 ` Mel Gorman
2011-02-10 21:00 ` Andrew Morton [this message]
2011-02-10 21:00 ` Andrew Morton
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=20110210130037.24dbde41.akpm@linux-foundation.org \
--to=akpm@linux-foundation.org \
--cc=hannes@cmpxchg.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mel@csn.ul.ie \
--cc=namhyung@gmail.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.