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 for Android: free password hash cracker in your pocket

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

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

On 01/07/2013 07:14 AM, Rik van Riel wrote:
> On 01/07/2013 03:12 AM, Shaohua Li wrote:
>>
>> We use access bit to age a page at page reclaim. When clearing pte
>> access bit,
>> we could skip tlb flush for the virtual address. The side effect is if
>> the pte
>> is in tlb and pte access bit is unset, when cpu access the page again,
>> cpu will
>> not set pte's access bit. So next time page reclaim can reclaim hot pages
>> wrongly, but this doesn't corrupt anything. And according to intel
>> manual, tlb
>> has less than 1k entries, which coverers < 4M memory. In today's system,
>> several giga byte memory is normal. After page reclaim clears pte
>> access bit
>> and before cpu access the page again, it's quite unlikely this page's
>> pte is
>> still in TLB. Skiping the tlb flush for this case sounds ok to me.
> 
> Agreed. In current systems, it can take a minute to write
> all of memory to disk, while context switch (natural TLB
> flush) times are in the dozens-of-millisecond timeframes.
> 

I'm confused.  We used to do this since time immemorial, so if we aren't
doing that now, that meant something changed somewhere along the line.
It would be good to figure out if that was an intentional change or
accidental.

	-hpa


--
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/