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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <c1ebaefd-ea60-b0f0-1c45-06ac3c502b5b@redhat.com>
Date:   Tue, 1 Oct 2019 20:41:26 +0200
From:   David Hildenbrand <david@...hat.com>
To:     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, nitesh@...hat.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

>> 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