From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qk1-f199.google.com (mail-qk1-f199.google.com [209.85.222.199]) by kanga.kvack.org (Postfix) with ESMTP id 91E9C8E0001 for ; Mon, 17 Sep 2018 06:01:16 -0400 (EDT) Received: by mail-qk1-f199.google.com with SMTP id a70-v6so13922104qkb.16 for ; Mon, 17 Sep 2018 03:01:16 -0700 (PDT) Received: from smtp-fw-9102.amazon.com (smtp-fw-9102.amazon.com. [207.171.184.29]) by mx.google.com with ESMTPS id b20-v6si7420621qta.378.2018.09.17.03.01.14 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 17 Sep 2018 03:01:15 -0700 (PDT) From: Julian Stecklina Subject: Re: Redoing eXclusive Page Frame Ownership (XPFO) with isolated CPUs in mind (for KVM to isolate its guests per CPU) References: Date: Mon, 17 Sep 2018 12:01:02 +0200 In-Reply-To: (Juerg Haefliger's message of "Thu, 13 Sep 2018 08:11:49 +0200") Message-ID: MIME-Version: 1.0 Content-Type: text/plain Sender: owner-linux-mm@kvack.org List-ID: To: Juerg Haefliger Cc: Linus Torvalds , David Woodhouse , Konrad Rzeszutek Wilk , deepa.srinivasan@oracle.com, Jim Mattson , Andrew Cooper , Linux Kernel Mailing List , Boris Ostrovsky , linux-mm , Thomas Gleixner , joao.m.martins@oracle.com, pradeep.vincent@oracle.com, Andi Kleen , Khalid Aziz , kanth.ghatraju@oracle.com, Liran Alon , Kees Cook , Kernel Hardening , chris.hyser@oracle.com, Tyler Hicks , John Haxby , Jon Masters Juerg Haefliger writes: >> I've updated my XPFO branch[1] to make some of the debugging optional >> and also integrated the XPFO bookkeeping with struct page, instead of >> requiring CONFIG_PAGE_EXTENSION, which removes some checks in the hot >> path. > > FWIW, that was my original design but there was some resistance to > adding more to the page struct and page extension was suggested > instead. >>From looking at both versions, I have to say that having the metadata in struct page makes the code easier to understand and removes some special cases and bookkeeping. > I'm wondering how much performance we're loosing by having to split > hugepages. Any chance this can be quantified somehow? Maybe we can > have a pool of some sorts reserved for userpages and group allocations > so that we can track the XPFO state at the hugepage level instead of > at the 4k level to prevent/reduce page splitting. Not sure if that > causes issues or has any unwanted side effects though... Optimizing the allocation/deallocation path might be worthwhile, because that's where most of the overhead goes. I haven't looked into how to do this yet. I'd appreciate if someone has pointers to code that tries to achieve similar functionality to get me started. That being said, I'm wondering whether we have unrealistic expectations about the overhead here and whether it's worth turning this patch into something far more complicated. Opinions? Julian -- Amazon Development Center Germany GmbH Berlin - Dresden - Aachen main office: Krausenstr. 38, 10117 Berlin Geschaeftsfuehrer: Dr. Ralf Herbrich, Christian Schlaeger Ust-ID: DE289237879 Eingetragen am Amtsgericht Charlottenburg HRB 149173 B