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=-0.8 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS 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 1F25CFC6196 for ; Fri, 8 Nov 2019 20:29:53 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id C24C4214DA for ; Fri, 8 Nov 2019 20:29:52 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org C24C4214DA Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=linux.intel.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 3A0126B0003; Fri, 8 Nov 2019 15:29:52 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 350B06B0006; Fri, 8 Nov 2019 15:29:52 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 2657A6B0007; Fri, 8 Nov 2019 15:29:52 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0029.hostedemail.com [216.40.44.29]) by kanga.kvack.org (Postfix) with ESMTP id 0D9DA6B0003 for ; Fri, 8 Nov 2019 15:29:52 -0500 (EST) Received: from smtpin22.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with SMTP id 8A404824999B for ; Fri, 8 Nov 2019 20:29:51 +0000 (UTC) X-FDA: 76134251382.22.pan61_902f9b455813b X-HE-Tag: pan61_902f9b455813b X-Filterd-Recvd-Size: 4605 Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by imf22.hostedemail.com (Postfix) with ESMTP for ; Fri, 8 Nov 2019 20:29:50 +0000 (UTC) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga001.jf.intel.com ([10.7.209.18]) by fmsmga101.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 08 Nov 2019 12:29:48 -0800 X-IronPort-AV: E=Sophos;i="5.68,283,1569308400"; d="scan'208";a="286592202" Received: from ahduyck-desk1.jf.intel.com ([10.7.198.76]) by orsmga001-auth.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 08 Nov 2019 12:29:47 -0800 Message-ID: <3161e0ec205852f8fcd1559f2dc177e42549708b.camel@linux.intel.com> Subject: Re: + mm-introduce-reported-pages.patch added to -mm tree From: Alexander Duyck To: Mel Gorman 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 Date: Fri, 08 Nov 2019 12:29:47 -0800 In-Reply-To: <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> <20191108184124.GV3016@techsingularity.net> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.30.5 (3.30.5-1.fc29) MIME-Version: 1.0 Content-Transfer-Encoding: 7bit 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, 2019-11-08 at 18:41 +0000, Mel Gorman wrote: > 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. So quick question. Any issue with me manipulating the lists like you do with the compaction code? I ask because most of the overhead I was encountering was likely due to walking the list so many times. If I do the split/splice style logic that should reduce the total number of trips through the free lists since I could push the reported pages to the tail of the list. For now I am working on that as an alternate patch to the existing reported_boundary approach just as an experiment. Thanks. - Alex