From: Dave Hansen <dave@sr71.net>
To: Cody P Schafer <cody@linux.vnet.ibm.com>
Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org, cl@linux.com
Subject: Re: [RFC][PATCH] mm: percpu pages: up batch size to fix arithmetic?? errror
Date: Wed, 11 Sep 2013 16:58:50 -0700 [thread overview]
Message-ID: <523103BA.7010202@sr71.net> (raw)
In-Reply-To: <5230F7DD.90905@linux.vnet.ibm.com>
On 09/11/2013 04:08 PM, Cody P Schafer wrote:
> So we have this variable called "batch", and the code is trying to store
> the _average_ number of pcp pages we want into it (not the batchsize),
> and then we divide our "average" goal by 4 to get a batchsize. All the
> comments refer to the size of the pcp pagesets, not to the pcp pageset
> batchsize.
That's a good point, I guess. I was wondering the same thing.
> Looking further, in current code we don't refill the pcp pagesets unless
> they are completely empty (->low was removed a while ago), and then we
> only add ->batch pages.
>
> Has anyone looked at what type of average pcp sizing the current code
> results in?
It tends to be within a batch of either ->high (when we are freeing lots
of pages) or ->low (when alloc'ing lots). I don't see a whole lot of
bouncing around in the middle. For instance, there aren't a lot of gcc
or make instances during a kernel compile that fit in to the ~0.75MB
->high limit.
Just a dumb little thing like this during a kernel compile on my 4-cpu
laptop:
while true; do cat /proc/zoneinfo | egrep 'count:' | tail -4; done >
pcp-counts.1.txt
cat pcp-counts.1.txt | awk '{print $2}' | sort -n | uniq -c | sort -n
says that at least ~1/2 of the time we have <=10 pages. That makes
sense since the compile spends all of its runtime (relatively slowly)
doing allocations. It frees all its memory really quickly when it
exits, so the window to see the times when the pools are full is smaller
than when they are empty.
I'm struggling to think of a case where the small batch sizes make sense
these days. Maybe if you're running a lot of little programs like ls or
awk?
--
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>
prev parent reply other threads:[~2013-09-11 23:59 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-09-11 22:08 [RFC][PATCH] mm: percpu pages: up batch size to fix arithmetic?? errror Dave Hansen
2013-09-11 23:08 ` Cody P Schafer
2013-09-11 23:21 ` Cody P Schafer
2013-09-12 0:20 ` Dave Hansen
2013-09-12 14:16 ` Christoph Lameter
2013-09-12 15:21 ` Dave Hansen
2013-09-11 23:58 ` Dave Hansen [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=523103BA.7010202@sr71.net \
--to=dave@sr71.net \
--cc=cl@linux.com \
--cc=cody@linux.vnet.ibm.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).