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 A3A05C5DF63 for ; Wed, 6 Nov 2019 16:35:47 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 6D70920650 for ; Wed, 6 Nov 2019 16:35:47 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 6D70920650 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 05AB66B0003; Wed, 6 Nov 2019 11:35:47 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 00C226B0006; Wed, 6 Nov 2019 11:35:46 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E63686B0007; Wed, 6 Nov 2019 11:35:46 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id CCD0B6B0003 for ; Wed, 6 Nov 2019 11:35:46 -0500 (EST) Received: from smtpin04.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with SMTP id 81FD1181AEF1D for ; Wed, 6 Nov 2019 16:35:46 +0000 (UTC) X-FDA: 76126403892.04.drop40_15301dd1a9006 X-HE-Tag: drop40_15301dd1a9006 X-Filterd-Recvd-Size: 4911 Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by imf47.hostedemail.com (Postfix) with ESMTP for ; Wed, 6 Nov 2019 16:35:45 +0000 (UTC) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga003.jf.intel.com ([10.7.209.27]) by fmsmga102.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 06 Nov 2019 08:35:44 -0800 X-IronPort-AV: E=Sophos;i="5.68,275,1569308400"; d="scan'208";a="205385097" Received: from ahduyck-desk1.jf.intel.com ([10.7.198.76]) by orsmga003-auth.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 06 Nov 2019 08:35:44 -0800 Message-ID: Subject: Re: + mm-introduce-reported-pages.patch added to -mm tree From: Alexander Duyck To: David Hildenbrand , Michal Hocko Cc: akpm@linux-foundation.org, aarcange@redhat.com, dan.j.williams@intel.com, dave.hansen@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: Wed, 06 Nov 2019 08:35:43 -0800 In-Reply-To: References: <20191106121605.GH8314@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: quoted-printable 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 Wed, 2019-11-06 at 15:09 +0100, David Hildenbrand wrote: > > Am 06.11.2019 um 13:16 schrieb Michal Hocko : > >=20 > > =EF=BB=BFI didn't have time to read through newer versions of this pa= tch series > > but I remember there were concerns about this functionality being pul= led > > into the page allocator previously both by me and Mel [1][2]. Have th= ose been=20 > > addressed? I do not see an ack from Mel or any other MM people. Is th= ere > > really a consensus that we want something like that living in the > > allocator? >=20 > I don=E2=80=98t think there is. The discussion is still ongoing (althou= gh quiet, > Nitesh is working on a new version AFAIK). I think we should not rush > this. How much time is needed to get a review? I waited 2 weeks since posting v12 and the only comments I got on the code were from Andrew. Most of thi= s hasn't changed much since v10 and that was posted back in mid September. = I have been down to making small tweaks here and there and haven't had any real critiques on the approach since Mel had the comments about conflicts with compaction which I addressed by allowing compaction to punt the reporter out so that it could split and splice the lists as it walked through them. The fact is we have been discussing this since 2011. I think it makes sense at this point to push a solution if we can do so without impacting performance negatively. It isn't as though this exposes a userspace interface so we could always go back and change the internal implementation if Nitesh comes up with something that works out better than this. The only piece that will be locked down is the virtio interface and both Nitesh's solution and mine are using the same one at this point. > > There has also been a different approach discussed and from [3] > > (referenced by the cover letter) I can only see > >=20 > > : Then Nitesh's solution had changed to the bitmap approach[7]. Howev= er it > > : has been pointed out that this solution doesn't deal with sparse me= mory, > > : hotplug, and various other issues. > >=20 > > which looks more like something to be done than a fundamental > > roadblocks. >=20 > I second that. As I stated a couple of times already, it is totally fin= e > to not support all environments initially (hotunplug, sparse zones). Th= e > major difference I am interested in is performance comparison. Then we > have to decide if the gain in performance is worth core buddy > modifications. I only modified three spots in the buddy allocator really. I forced pages added to the tail of the list to be placed before the iterator, I added logic so that if the page pointed to by the iterator is pulled from the list we can wind the pointer back, and I added a function that triggers the page reporting to __free_one_page. If nothing else we could consider my solution the baseline for now. If Nitesh comes up with something better we could then look at replacing my code with his. Since he is now using the same virtio-balloon interface I am there isn't really much point in holding things up since we could always refactor/replace the implementation later if Nitesh comes up with = a better approach.