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 65588C5DF63 for ; Wed, 6 Nov 2019 17:48:18 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 2E49D20869 for ; Wed, 6 Nov 2019 17:48:18 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 2E49D20869 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 C36436B0006; Wed, 6 Nov 2019 12:48:17 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id BE6626B0007; Wed, 6 Nov 2019 12:48:17 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B23876B0008; Wed, 6 Nov 2019 12:48:17 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0121.hostedemail.com [216.40.44.121]) by kanga.kvack.org (Postfix) with ESMTP id 9D74A6B0006 for ; Wed, 6 Nov 2019 12:48:17 -0500 (EST) Received: from smtpin16.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with SMTP id 64BCE181AEF15 for ; Wed, 6 Nov 2019 17:48:17 +0000 (UTC) X-FDA: 76126586634.16.hill40_4849097515162 X-HE-Tag: hill40_4849097515162 X-Filterd-Recvd-Size: 4812 Received: from mga12.intel.com (mga12.intel.com [192.55.52.136]) by imf04.hostedemail.com (Postfix) with ESMTP for ; Wed, 6 Nov 2019 17:48:16 +0000 (UTC) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga008.jf.intel.com ([10.7.209.65]) by fmsmga106.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 06 Nov 2019 09:48:15 -0800 X-IronPort-AV: E=Sophos;i="5.68,275,1569308400"; d="scan'208";a="196279334" Received: from ahduyck-desk1.jf.intel.com ([10.7.198.76]) by orsmga008-auth.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 06 Nov 2019 09:48:15 -0800 Message-ID: Subject: Re: + mm-introduce-reported-pages.patch added to -mm tree From: Alexander Duyck To: Michal Hocko Cc: 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, 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 09:48:14 -0800 In-Reply-To: <20191106165416.GO8314@dhcp22.suse.cz> References: <20191106121605.GH8314@dhcp22.suse.cz> <20191106165416.GO8314@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 17:54 +0100, Michal Hocko wrote: > On Wed 06-11-19 08:35:43, Alexander Duyck wrote: > > 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 thi= s patch series > > > > but I remember there were concerns about this functionality being= pulled > > > > into the page allocator previously both by me and Mel [1][2]. Hav= e those been=20 > > > > addressed? I do not see an ack from Mel or any other MM people. I= s there > > > > 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 (al= though quiet, > > > Nitesh is working on a new version AFAIK). I think we should not ru= sh > > > this. > >=20 > > How much time is needed to get a review? I waited 2 weeks since posti= ng > > v12 and the only comments I got on the code were from Andrew. Most of= this > > hasn't changed much since v10 and that was posted back in mid Septemb= er. 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 confl= icts > > 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. >=20 > Well, people are busy and MM community is not a large one. I cannot > really help you much other than keep poking those people and give > reasonable arguments so they decide to ack your patch. I get that. But v10 was posted in mid September. Back then we had a discussion about addressing what Mel had mentioned and I had mentioned then that I had addressed it by allowing compaction to essentially reset the reporter to get it out of the list so compaction could do this split and splice tumbling logic. > I definitely do not intent to nack this work, I just have maintainabili= ty > concerns and considering there is an alternative approach that does not > require to touch page allocator internals and which we need to compare > against then I do not really think there is any need to push something > in right away. Or is there any pressing reason to have this merged righ= t > now? The alternative approach doesn't touch the page allocator, however it still has essentially the same changes to __free_one_page. I suspect the performance issue seen is mostly due to the fact that because it doesn't touch the page allocator it is taking the zone lock and probing the page for each set bit to see if the page is still free. As such the performanc= e regression seen gets worse the lower the order used for reporting. Also I suspect Nitesh's patches are also in need of further review. I hav= e provided feedback however my focus ended up being on more the kernel panics and 30% performance regression rather than debating architecture.