>> 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? -- Thanks, David / dhildenb
