linux-kernel - Re: [RFC]x86: clearing access bit don't flush tlb

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] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 08 Jan 2013 00:08:44 -0500
From:	Rik van Riel <riel@...hat.com>
To:	"H. Peter Anvin" <hpa@...or.com>
CC:	Shaohua Li <shli@...nel.org>, linux-mm@...ck.org,
	linux-kernel@...r.kernel.org, akpm@...ux-foundation.org,
	mingo@...hat.com, hughd@...gle.com
Subject: Re: [RFC]x86: clearing access bit don't flush tlb

On 01/08/2013 12:03 AM, H. Peter Anvin wrote:
> On 01/07/2013 08:55 PM, Shaohua Li wrote:
>>
>> I searched a little bit, the change (doing TLB flush to clear access bit) is
>> made between 2.6.7 - 2.6.8, I can't find the changelog, but I found a patch:
>> http://www.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.7-rc2/2.6.7-rc2-mm2/broken-out/mm-flush-tlb-when-clearing-young.patch
>>
>> The changelog declaims this is for arm/ppc/ppc64.
>>
>
> Not really.  It says that those have stumbled over it already.  It is
> true in general that this change will make very frequently used pages
> (which stick in the TLB) candidates for eviction.

That is only true if the pages were to stay in the TLB for a
very very long time.  Probably multiple seconds.

> x86 would seem to be just as affected, although possibly with a
> different frequency.
>
> Do we have any actual metrics on anything here?

I suspect that if we do need to force a TLB flush for page
reclaim purposes, it may make sense to do that TLB flush
asynchronously. For example, kswapd could kick off a TLB
flush of every CPU in the system once a second, when the
system is under pageout pressure.

We would have to do this in a smart way, so the kswapds
from multiple nodes do not duplicate the work.

If people want that kind of functionality, I would be
happy to cook up an RFC patch.

-- 
All rights reversed
--
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/