linux-kernel - Re: [PATCH v11 0/6] mm / virtio: Provide support for unused page reporting

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]

Message-ID: <530ed9b2-aabd-da39-6717-33a6dd33f92d@redhat.com>
Date:   Tue, 1 Oct 2019 15:17:36 -0400
From:   Nitesh Narayan Lal <nitesh@...hat.com>
To:     David Hildenbrand <david@...hat.com>,
        Alexander Duyck <alexander.h.duyck@...ux.intel.com>,
        Alexander Duyck <alexander.duyck@...il.com>,
        virtio-dev@...ts.oasis-open.org, kvm@...r.kernel.org,
        mst@...hat.com, dave.hansen@...el.com,
        linux-kernel@...r.kernel.org, willy@...radead.org,
        mhocko@...nel.org, linux-mm@...ck.org, akpm@...ux-foundation.org,
        mgorman@...hsingularity.net, vbabka@...e.cz, osalvador@...e.de
Cc:     yang.zhang.wz@...il.com, pagupta@...hat.com,
        konrad.wilk@...cle.com, riel@...riel.com, lcapitulino@...hat.com,
        wei.w.wang@...el.com, aarcange@...hat.com, pbonzini@...hat.com,
        dan.j.williams@...el.com
Subject: Re: [PATCH v11 0/6] mm / virtio: Provide support for unused page
 reporting


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