From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dan Magenheimer Subject: RE: [RFC 00/10] KVM: Add TMEM host/guest support Date: Tue, 12 Jun 2012 09:40:36 -0700 (PDT) Message-ID: <4d71487c-470c-4f48-b6f3-e590a901c837@default> References: <1338988073-6913-1-git-send-email-levinsasha928@gmail.com> <4FCF5A08.7080306@redhat.com> <1339161641.3200.15.camel@lappy> <4FD5A7CE.5060205@redhat.com> <1339410370.4999.35.camel@lappy> <4FD5DA5F.7090905@redhat.com> <06ae24f8-5083-49c4-9b9f-af553e1cdf68@default> <4FD625A7.5020707@redhat.com> <022f701e-d40f-4b44-b960-effa0d320d4a@default> <4FD7156A.8050207@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8BIT Cc: Sasha Levin , mtosatti@redhat.com, gregkh@linuxfoundation.org, sjenning@linux.vnet.ibm.com, Konrad Wilk , kvm@vger.kernel.org To: Avi Kivity Return-path: Received: from rcsinet15.oracle.com ([148.87.113.117]:30160 "EHLO rcsinet15.oracle.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752252Ab2FLQlr convert rfc822-to-8bit (ORCPT ); Tue, 12 Jun 2012 12:41:47 -0400 In-Reply-To: <4FD7156A.8050207@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: > From: Avi Kivity [mailto:avi@redhat.com] > Subject: Re: [RFC 00/10] KVM: Add TMEM host/guest support I started off with a point-by-point comment on most of your responses about the tradeoffs of how tmem works, but decided it best to simply say we disagree and kvm-tmem will need to prove who is right. > >> Sorry, no, first demonstrate no performance regressions, then we can > >> talk about performance improvements. > > > > Well that's an awfully hard bar to clear, even with any of the many > > changes being merged every release into the core Linux mm subsystem. > > Any change to memory management will have some positive impacts on some > > workloads and some negative impacts on others. > > Right, that's too harsh. But these benchmarks show a doubling (or even > more) of cpu overhead, and that is whether the cache is effective or > not. That is simply way too much to consider. One point here... remember you have contrived a worst case scenario. The one case Sasha provided outside of that contrived worst case, as you commented, looks very nice. So the costs/benefits remain to be seen over a wider set of workloads. Also, even that contrived case should look quite a bit better with WasActive properly implemented. > Look at the block, vfs, and mm layers. Huge pains have been taken to > batch everything and avoid per-page work -- 20 years of not having > enough cycles. And here you throw all this out of the window with > per-page crossing of the guest/host boundary. Well, to be fair, those 20 years of effort were because (1) disk seeks are a million times slower than an in-RAM page copy and (2) SMP systems were rare and expensive. The world changes...