Juerg Haefliger <juergh@xxxxxxxxx> 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
