linux-kernel - Re: [PATCH v3 00/21] KVM: Dirty ring interface

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]

Date:   Thu, 9 Jan 2020 11:40:23 -0500
From:   "Michael S. Tsirkin" <mst@...hat.com>
To:     Peter Xu <peterx@...hat.com>
Cc:     kvm@...r.kernel.org, linux-kernel@...r.kernel.org,
        Christophe de Dinechin <dinechin@...hat.com>,
        Paolo Bonzini <pbonzini@...hat.com>,
        Sean Christopherson <sean.j.christopherson@...el.com>,
        Yan Zhao <yan.y.zhao@...el.com>,
        Alex Williamson <alex.williamson@...hat.com>,
        Jason Wang <jasowang@...hat.com>,
        Kevin Kevin <kevin.tian@...el.com>,
        Vitaly Kuznetsov <vkuznets@...hat.com>,
        "Dr . David Alan Gilbert" <dgilbert@...hat.com>
Subject: Re: [PATCH v3 00/21] KVM: Dirty ring interface

On Thu, Jan 09, 2020 at 11:17:42AM -0500, Peter Xu wrote:
> On Thu, Jan 09, 2020 at 10:59:50AM -0500, Michael S. Tsirkin wrote:
> > On Thu, Jan 09, 2020 at 09:57:08AM -0500, Peter Xu wrote:
> > > Branch is here: https://github.com/xzpeter/linux/tree/kvm-dirty-ring
> > > (based on kvm/queue)
> > > 
> > > Please refer to either the previous cover letters, or documentation
> > > update in patch 12 for the big picture.
> > 
> > I would rather you pasted it here. There's no way to respond otherwise.
> 
> Sure, will do in the next post.
> 
> > 
> > For something that's presumably an optimization, isn't there
> > some kind of testing that can be done to show the benefits?
> > What kind of gain was observed?
> 
> Since the interface seems to settle soon, maybe it's time to work on
> the QEMU part so I can give some number.  It would be interesting to
> know the curves between dirty logging and dirty ring even for some
> small vms that have some workloads inside.
> 
> > 
> > I know it's mostly relevant for huge VMs, but OTOH these
> > probably use huge pages.
> 
> Yes huge VMs could benefit more, especially if the dirty rate is not
> that high, I believe.  Though, could you elaborate on why huge pages
> are special here?
> 
> Thanks,

With hugetlbfs there are less bits to test: e.g. with 2M pages a single
bit set marks 512 pages as dirty.  We do not take advantage of this
but it looks like a rather obvious optimization.

> -- 
> Peter Xu