On 10/1/19 2:41 PM, David Hildenbrand wrote: >>> I think Michal asked for a performance comparison against Nitesh's >>> approach, to evaluate if keeping the reported state + tracking inside >>> the buddy is really worth it. Do you have any such numbers already? (or >>> did my tired eyes miss them in this cover letter? :/) >>> >> I thought what Michal was asking for was what was the benefit of using the >> boundary pointer. I added a bit up above and to the description for patch >> 3 as on a 32G VM it adds up to about a 18% difference without factoring in >> the page faulting and zeroing logic that occurs when we actually do the >> madvise. > "I would still be happier if the allocator wouldn't really have to > bother about somebody snooping its internal state to do its own thing. > So make sure to describe why and how much this really matters. > [...] > if you gave some rough numbers to quantify how much overhead for > different solutions we are talking about here. > " > > Could be that I'm misreading Michals comment, but I'd be interested in > the "how much" as well. > >> Do we have a working patch set for Nitesh's code? The last time I tried >> running his patch set I ran into issues with kernel panics. If we have a >> known working/stable patch set I can give it a try. > @Nitesh, is there a working branch? For some unknown reason, I received these set of emails just now :) That's why couldn't respond earlier. > > -- Thanks Nitesh
