linux-kernel - Re: [RFC][PATCH] mm: percpu pages: up batch size to fix arithmetic?? errror

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <5231DBE9.2090008@sr71.net>
Date:	Thu, 12 Sep 2013 08:21:13 -0700
From:	Dave Hansen <dave@...1.net>
To:	Christoph Lameter <cl@...ux.com>
CC:	Cody P Schafer <cody@...ux.vnet.ibm.com>, linux-mm@...ck.org,
	linux-kernel@...r.kernel.org
Subject: Re: [RFC][PATCH] mm: percpu pages: up batch size to fix arithmetic??
 errror

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 from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/