From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.3 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 6B212C5DF60 for ; Fri, 8 Nov 2019 18:41:29 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 3862A2087E for ; Fri, 8 Nov 2019 18:41:29 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 3862A2087E Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=techsingularity.net Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id C030D6B0005; Fri, 8 Nov 2019 13:41:28 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id BB39B6B0006; Fri, 8 Nov 2019 13:41:28 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id AA2C96B0007; Fri, 8 Nov 2019 13:41:28 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0183.hostedemail.com [216.40.44.183]) by kanga.kvack.org (Postfix) with ESMTP id 964B56B0005 for ; Fri, 8 Nov 2019 13:41:28 -0500 (EST) Received: from smtpin10.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with SMTP id 57552824999B for ; Fri, 8 Nov 2019 18:41:28 +0000 (UTC) X-FDA: 76133978256.10.value65_46fa362779528 X-HE-Tag: value65_46fa362779528 X-Filterd-Recvd-Size: 3973 Received: from outbound-smtp07.blacknight.com (outbound-smtp07.blacknight.com [46.22.139.12]) by imf06.hostedemail.com (Postfix) with ESMTP for ; Fri, 8 Nov 2019 18:41:27 +0000 (UTC) Received: from mail.blacknight.com (pemlinmail01.blacknight.ie [81.17.254.10]) by outbound-smtp07.blacknight.com (Postfix) with ESMTPS id C27301C2277 for ; Fri, 8 Nov 2019 18:41:25 +0000 (GMT) Received: (qmail 7623 invoked from network); 8 Nov 2019 18:41:25 -0000 Received: from unknown (HELO techsingularity.net) (mgorman@techsingularity.net@[84.203.23.195]) by 81.17.254.9 with ESMTPSA (AES256-SHA encrypted, authenticated); 8 Nov 2019 18:41:25 -0000 Date: Fri, 8 Nov 2019 18:41:24 +0000 From: Mel Gorman To: Alexander Duyck Cc: Michal Hocko , David Hildenbrand , akpm@linux-foundation.org, aarcange@redhat.com, dan.j.williams@intel.com, dave.hansen@intel.com, konrad.wilk@oracle.com, lcapitulino@redhat.com, mm-commits@vger.kernel.org, mst@redhat.com, osalvador@suse.de, pagupta@redhat.com, pbonzini@redhat.com, riel@surriel.com, vbabka@suse.cz, wei.w.wang@intel.com, willy@infradead.org, yang.zhang.wz@gmail.com, linux-mm@kvack.org Subject: Re: + mm-introduce-reported-pages.patch added to -mm tree Message-ID: <20191108184124.GV3016@techsingularity.net> References: <20191106165416.GO8314@dhcp22.suse.cz> <20191106221150.GR3016@techsingularity.net> <673862eb7f0425f638ea3fc507d0e8049ee4133c.camel@linux.intel.com> <20191107102045.GS3016@techsingularity.net> <73c0477e6e1672d5d36d4aa673b64cda10590a9d.camel@linux.intel.com> <20191108094340.GT3016@techsingularity.net> <4c3e787b5db923de8599eafee46c1235eacd2432.camel@linux.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline In-Reply-To: <4c3e787b5db923de8599eafee46c1235eacd2432.camel@linux.intel.com> User-Agent: Mutt/1.10.1 (2018-07-13) X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Fri, Nov 08, 2019 at 08:17:49AM -0800, Alexander Duyck wrote: > > > > > > From your perspective, I see it's a bit annoying because in the final > > result, the code should be identical. However, it'll be a lot clearer > > during review what is required, what level of complexity optimisations > > add and the performance of it. The changelog should include what metric > > you are using to evaluate the performance, the test case and the delta. It > > also will be easier from a debugging perspective as minimally a bisection > > could identify if a bug was due to the core mechanism itself or one of > > the optimisations. Finally, it leaves open the possibility that someone > > can evaluate a completely different set of optimisations. Whatever the > > alternative approaches are, the actual interface to virtio ballon surely > > is the same (I don't actually know, I just can't see why the virtio ABI > > would be depend on how the pages are isolated, tracked and reported). > > The virtio-balloon interface is the same at this point between my solution > and Nitesh's. So the only real disagreement in terms of the two solutions > is about keeping the bit in the page and the list manipulation versus the > external bitmap and the hunt and peck approach. > This is good news because it means that when/if Nitesh's approach is ready that the optimisations can be reverted and the new approach applied and give a like-like comparison if appropriate. The core feature and interface to userspace would remain the same and stay available regardless of how it's optimised. Maybe it's the weekend talking but I think structuring the series like that will allow forward progress to be made. -- Mel Gorman SUSE Labs