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.5 required=3.0 tests=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 1498AFA372C for ; Fri, 8 Nov 2019 09:57:17 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id D39CF214DA for ; Fri, 8 Nov 2019 09:57:16 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org D39CF214DA Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 5C3346B000D; Fri, 8 Nov 2019 04:57:16 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 574636B026A; Fri, 8 Nov 2019 04:57:16 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 488F36B026B; Fri, 8 Nov 2019 04:57:16 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0127.hostedemail.com [216.40.44.127]) by kanga.kvack.org (Postfix) with ESMTP id 3474C6B000D for ; Fri, 8 Nov 2019 04:57:16 -0500 (EST) Received: from smtpin20.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with SMTP id D013998BC for ; Fri, 8 Nov 2019 09:57:15 +0000 (UTC) X-FDA: 76132657230.20.dog96_529eda101201 X-HE-Tag: dog96_529eda101201 X-Filterd-Recvd-Size: 4007 Received: from mx1.suse.de (mx2.suse.de [195.135.220.15]) by imf33.hostedemail.com (Postfix) with ESMTP for ; Fri, 8 Nov 2019 09:57:15 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx1.suse.de (Postfix) with ESMTP id 12139B287; Fri, 8 Nov 2019 09:57:14 +0000 (UTC) Date: Fri, 8 Nov 2019 10:57:13 +0100 From: Michal Hocko To: Alexander Duyck Cc: Dave Hansen , David Hildenbrand , akpm@linux-foundation.org, aarcange@redhat.com, dan.j.williams@intel.com, konrad.wilk@oracle.com, lcapitulino@redhat.com, mgorman@techsingularity.net, 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: <20191108095713.GC15658@dhcp22.suse.cz> References: <95a78ac2-73bf-2985-9769-e269e8d13d68@intel.com> <92C323F0-41BE-4988-8C39-1513FAC40458@redhat.com> <20191107174644.GA8314@dhcp22.suse.cz> <91ccd1e4a9077e22379edbaac2fd8c16897b1f7a.camel@linux.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <91ccd1e4a9077e22379edbaac2fd8c16897b1f7a.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 Thu 07-11-19 10:12:21, Alexander Duyck wrote: > On Thu, 2019-11-07 at 18:46 +0100, Michal Hocko wrote: [...] > > I have asked several times why there is such a push and received no > > answer but "this is taking too long" which I honestly do not care much. > > Especially when other virt people tend to agree that there is no need to > > rush here. > > Part of the rush, at least from my perspective, is that I don't have > indefinite time to work on this. I fully understand this! And I also feel the frustration. Been through that several times. > I am sure you are aware that maintaining > an external patch set can be a real chore and I would prefer to have it > merged and then maintain it as a part of the tree. Sure, keeping the code in sync is an additional burden. Having the code in just pushes the burden to everybody touching that subsystem in the future though. This is the maintenance cost we have to consider. Your approach of integrating a very narrow feature into the core allocator will require considering that usecase for future changes in the allocator. Maintaining metadata elsewhere doesn't impose that maintenance cost. Can we agree on this at least? Because feel we are circling around in this and previous discussions. > Then other changes can > be rebased on it instead of having to rebase it around other changes that > are going on. Well, that is not a real argument because alternatives are not an incremental change from the allocator POV. It is a different approach of maintaining metadata. Sure a different approach could replace your implementation (if it was merged) but what is the point of merging an approach that would be replaced? Just because you do not want to maintain your implmentation off tree? That is a poor argument to me. I completely agree with Mel. Let's start with a simple solution first (using existing page isolation interfaces sound like a good start to interact with the page allocator), establish a decent API for virtio and start optimizing from there. Last but not least, I would also recommend to be more explicit about workloads which are going to benefit from those performance optimizations. So far I have only seen some micro benchmarks results. Do we have any real workloads and see how your approach behaves so that we can compare that to the other approach? -- Michal Hocko SUSE Labs