linux-kernel - Re: [patch 12/13] GRU Driver V3 - export is_uv_system(), zap_page_range() & follow

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:	Mon, 7 Jul 2008 16:54:09 +0200
From:	Andrea Arcangeli <andrea@...ranet.com>
To:	Jack Steiner <steiner@....com>
Cc:	Christoph Hellwig <hch@...radead.org>, cl@...ux-foundation.org,
	hugh@...itas.com, akpm@...l.org, linux-kernel@...r.kernel.org,
	mingo@...e.hu, tglx@...utronix.de, holt@....com, linux-mm@...ck.org
Subject: Re: [patch 12/13] GRU Driver V3 -  export is_uv_system(),
	zap_page_range() & follow_page()

On Mon, Jul 07, 2008 at 09:39:16AM -0500, Jack Steiner wrote:
> Can you provide some additional details on the type of kernel API
> that could be exported to provide a pte lookup in atomic context?

mmu notifiers makes page pinning an obsolete thing so we want to get
rid of get_user_pages in KVM page fault fast path too (we want to keep
it in the slow path the same way as GRU does).

I tried to profile it and time spent in get_user_pages is quite
smaller than the time spent on follow_page. So I estimated we'll be
very lucky if getting rid of get_user_pages will even mark a 1%
speedup in real life benchmark, but still we want to optimize things
given this is so easy.

If calling follow_page directly is the right thing I don't know. Let's
say I'll postpone any minor-optimization work in this area to the time
mmu notifiers are merged in .27 as scheduled.

If the export of follow_page was going in before a more accurate
thought on what else we could do, I wouldn't be opposed because
eventually we'll have to export a new function anyway and this is a
one liner change, so it couldn't make life harder later if it goes in.

> I'll gladly make whatever changes are needed but need some pointers on
> the direction I should take....

Same here, and I'll join this more actively to help out as soon as we
can move to the next step (i.e. once mmu notifiers are in mainline).

Thanks everyone!!
--
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/