linux-kernel - Re: Populating multiple ptes at fault time

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]

Message-ID: <48D17A93.4000803@goop.org>
Date:	Wed, 17 Sep 2008 14:45:55 -0700
From:	Jeremy Fitzhardinge <jeremy@...p.org>
To:	Chris Snook <csnook@...hat.com>
CC:	Nick Piggin <nickpiggin@...oo.com.au>,
	Hugh Dickens <hugh@...itas.com>,
	Linux Memory Management List <linux-mm@...ck.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Avi Kivity <avi@...ranet.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Rik van Riel <riel@...hat.com>
Subject: Re: Populating multiple ptes at fault time

Chris Snook wrote:
> Is it still expensive when you're using nested page tables?

No, nested pagetables are the same as native to update, so the main
benefit in that case is the reduction of faults.

> We already have rather well-tested code in the VM to detect fault
> patterns, complete with userspace hints to set readahead policy.  It
> seems to me that if we're going to read nearby pages into pagecache,
> we might as well actually map them at the same time.  Duplicating the
> readahead code is probably a bad idea.

Right, that was my point.  I'm assuming that that machinery already
exists and would be available for use in this case.

>> Minor faults are easier; if the page already exists in memory, we should
>> just create mappings to it.  If neighbouring pages are also already
>> present, then we can can cheaply create mappings for them too.
>
> If we're mapping pagecache, then sure, this is really cheap, but
> speculatively allocating anonymous pages will hurt, badly, on many
> workloads.

OK, makes sense.  Does the access pattern detecting code measure access
patterns to anonymous mappings?

>> This seems like an obvious idea, so I'm wondering if someone has
>> prototyped it already to see what effects there are.  In the native
>> case, pte updates are much cheaper, so perhaps it doesn't help much
>> there, though it would potentially reduce the number of faults
>> needed. But I think there's scope for measurable benefits in the
>> virtual case.
>
> Sounds like something we might want to enable conditionally on the use
> of pv_ops features.

Perhaps, but I'd rather avoid it.  I'm hoping this is something we could
do that has - at worst - no effect on the native case, while improving
the virtual case.  The test matrix is already large enough without
adding another stateful switch.  After all, any side effect which makes
it a bad idea for the native case will probably be bad enough to
overwhelm any benefit in the virtual case.

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