From: Dave Hansen <dave@sr71.net>
To: Christoph Lameter <cl@linux.com>
Cc: Cody P Schafer <cody@linux.vnet.ibm.com>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: [RFC][PATCH] mm: percpu pages: up batch size to fix arithmetic?? errror
Date: Thu, 12 Sep 2013 08:21:13 -0700 [thread overview]
Message-ID: <5231DBE9.2090008@sr71.net> (raw)
In-Reply-To: <00000141128835e1-8664ca3a-c439-4d9d-89cb-308664595db4-000000@email.amazonses.com>
On 09/12/2013 07:16 AM, Christoph Lameter wrote:
> On Wed, 11 Sep 2013, Dave Hansen wrote:
>
>> 3. We want ->high to approximate the size of the cache which is
>> private to a given cpu. But, that's complicated by the L3 caches
>> and hyperthreading today.
>
> well lets keep it well below that. There are other caches (slab related
> f.e.) that are also in constant use.
At the moment, we've got a on-size-fits-all approach. If you have more
than 512MB of RAM in a zone, you get the high=186(744kb)/batch=31(124kb)
behavior. On my laptop, I've got 3500kB of L2+L3 for 4 logical cpus, or
~875kB/cpu. According to what you're saying, the high mark is probably
a _bit_ too high. On a modern server CPU, the caches are about double
that (per cpu).
>> I'll take one of my big systems and run it with some various ->high
>> settings and see if it makes any difference.
>
> Do you actually see contention issues on the locks? I think we have a
> tendency to batch too much in too many caches.
Nope. This all came out of me wondering what that /=4 did. It's pretty
clear that we've diverged a bit from what the original intent of the
code was. We need to at _least_ fix the comments up.
--
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>
WARNING: multiple messages have this Message-ID (diff)
From: Dave Hansen <dave@sr71.net>
To: Christoph Lameter <cl@linux.com>
Cc: Cody P Schafer <cody@linux.vnet.ibm.com>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: [RFC][PATCH] mm: percpu pages: up batch size to fix arithmetic?? errror
Date: Thu, 12 Sep 2013 08:21:13 -0700 [thread overview]
Message-ID: <5231DBE9.2090008@sr71.net> (raw)
In-Reply-To: <00000141128835e1-8664ca3a-c439-4d9d-89cb-308664595db4-000000@email.amazonses.com>
On 09/12/2013 07:16 AM, Christoph Lameter wrote:
> On Wed, 11 Sep 2013, Dave Hansen wrote:
>
>> 3. We want ->high to approximate the size of the cache which is
>> private to a given cpu. But, that's complicated by the L3 caches
>> and hyperthreading today.
>
> well lets keep it well below that. There are other caches (slab related
> f.e.) that are also in constant use.
At the moment, we've got a on-size-fits-all approach. If you have more
than 512MB of RAM in a zone, you get the high=186(744kb)/batch=31(124kb)
behavior. On my laptop, I've got 3500kB of L2+L3 for 4 logical cpus, or
~875kB/cpu. According to what you're saying, the high mark is probably
a _bit_ too high. On a modern server CPU, the caches are about double
that (per cpu).
>> I'll take one of my big systems and run it with some various ->high
>> settings and see if it makes any difference.
>
> Do you actually see contention issues on the locks? I think we have a
> tendency to batch too much in too many caches.
Nope. This all came out of me wondering what that /=4 did. It's pretty
clear that we've diverged a bit from what the original intent of the
code was. We need to at _least_ fix the comments up.
next prev parent reply other threads:[~2013-09-12 15:21 UTC|newest]
Thread overview: 14+ 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 22:08 ` Dave Hansen
2013-09-11 23:08 ` Cody P Schafer
2013-09-11 23:08 ` Cody P Schafer
2013-09-11 23:21 ` Cody P Schafer
2013-09-11 23:21 ` Cody P Schafer
2013-09-12 0:20 ` Dave Hansen
2013-09-12 0:20 ` Dave Hansen
2013-09-12 14:16 ` Christoph Lameter
2013-09-12 14:16 ` Christoph Lameter
2013-09-12 15:21 ` Dave Hansen [this message]
2013-09-12 15:21 ` Dave Hansen
2013-09-11 23:58 ` Dave Hansen
2013-09-11 23:58 ` 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=5231DBE9.2090008@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 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.