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 D0536C43331 for ; Thu, 7 Nov 2019 18:12:30 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 79EF321882 for ; Thu, 7 Nov 2019 18:12:30 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 79EF321882 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 F17FA6B0003; Thu, 7 Nov 2019 13:12:29 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id ECA066B0005; Thu, 7 Nov 2019 13:12:29 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id DDECC6B0007; Thu, 7 Nov 2019 13:12:29 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0151.hostedemail.com [216.40.44.151]) by kanga.kvack.org (Postfix) with ESMTP id C77606B0003 for ; Thu, 7 Nov 2019 13:12:29 -0500 (EST) Received: from smtpin20.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with SMTP id 5D0D2180AD806 for ; Thu, 7 Nov 2019 18:12:29 +0000 (UTC) X-FDA: 76130276418.20.move85_32c3d97c3e50e X-HE-Tag: move85_32c3d97c3e50e X-Filterd-Recvd-Size: 4039 Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) by imf48.hostedemail.com (Postfix) with ESMTP for ; Thu, 7 Nov 2019 18:12:28 +0000 (UTC) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga005.jf.intel.com ([10.7.209.41]) by orsmga101.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 07 Nov 2019 10:12:21 -0800 X-IronPort-AV: E=Sophos;i="5.68,278,1569308400"; d="scan'208";a="377514173" Received: from ahduyck-desk1.jf.intel.com ([10.7.198.76]) by orsmga005-auth.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 07 Nov 2019 10:12:21 -0800 Message-ID: <91ccd1e4a9077e22379edbaac2fd8c16897b1f7a.camel@linux.intel.com> Subject: Re: + mm-introduce-reported-pages.patch added to -mm tree From: Alexander Duyck To: Michal Hocko , Dave Hansen Cc: 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 Date: Thu, 07 Nov 2019 10:12:21 -0800 In-Reply-To: <20191107174644.GA8314@dhcp22.suse.cz> References: <95a78ac2-73bf-2985-9769-e269e8d13d68@intel.com> <92C323F0-41BE-4988-8C39-1513FAC40458@redhat.com> <20191107174644.GA8314@dhcp22.suse.cz> 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 Thu, 2019-11-07 at 18:46 +0100, Michal Hocko wrote: > On Thu 07-11-19 09:12:01, Dave Hansen wrote: > [...] > > Both approaches seem totally reasonable to me. I don't like Alex's > > pokes into the core of the allocator, but I also don't like Nitesh's > > extra data structures and the (yet unimplemented) code that it will take > > to make them handle all the things they need to like hotplug. > > Well, I would argue that an extra data structure belongs to the user who > is actually using it. Compare that with metadata that is de-facto > maintain athe allocator level which has no real knowledge about the end > user. This is an inherently fragile design as Mel points out in his > earlier email in this thread. I can live with that if that is _really_ > necessary but I would rather not to go that way if there is other way. So to address things I am going to split out the list manipulation into a separate patch as Mel suggested. So in terms of metadata that will leave us with 3 pieces; the PageReported bit, the reported_pages statistics, and the boundary pointers. I will add each one in a separate patch and track the effect of each as I go. > > There's also a common kernel/hypervisor ABI that's *SHARED* between the > > two approaches. That's really the only thing that would marry us to one > > approach versus the other forever. > > > > Am I missing something? What's the harm in merging the implementation > > that's ready today? If a better one comes along, we'll rip out the ~15 > > lines of code in page_alloc.c and merge the better one. > > 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 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. Then other changes can be rebased on it instead of having to rebase it around other changes that are going on.