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 5289DC5DF60 for ; Thu, 7 Nov 2019 17:46:51 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 20C2F206A3 for ; Thu, 7 Nov 2019 17:46:51 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 20C2F206A3 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 B0D756B0003; Thu, 7 Nov 2019 12:46:50 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id AE56B6B0005; Thu, 7 Nov 2019 12:46:50 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A22366B0007; Thu, 7 Nov 2019 12:46:50 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0180.hostedemail.com [216.40.44.180]) by kanga.kvack.org (Postfix) with ESMTP id 8D7CE6B0003 for ; Thu, 7 Nov 2019 12:46:50 -0500 (EST) Received: from smtpin28.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with SMTP id F38F852A3 for ; Thu, 7 Nov 2019 17:46:49 +0000 (UTC) X-FDA: 76130211738.28.pets94_75d0c8f47db62 X-HE-Tag: pets94_75d0c8f47db62 X-Filterd-Recvd-Size: 2894 Received: from mx1.suse.de (mx2.suse.de [195.135.220.15]) by imf08.hostedemail.com (Postfix) with ESMTP for ; Thu, 7 Nov 2019 17:46:49 +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 CA472AC12; Thu, 7 Nov 2019 17:46:47 +0000 (UTC) Date: Thu, 7 Nov 2019 18:46:44 +0100 From: Michal Hocko To: Dave Hansen Cc: David Hildenbrand , Alexander Duyck , 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: <20191107174644.GA8314@dhcp22.suse.cz> References: <95a78ac2-73bf-2985-9769-e269e8d13d68@intel.com> <92C323F0-41BE-4988-8C39-1513FAC40458@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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 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. > 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. -- Michal Hocko SUSE Labs