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 58116C43331 for ; Fri, 8 Nov 2019 00:42:47 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 004ED2084C for ; Fri, 8 Nov 2019 00:42:46 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 004ED2084C 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 84D456B0005; Thu, 7 Nov 2019 19:42:45 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 7FD446B0006; Thu, 7 Nov 2019 19:42:45 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 6C4BF6B0007; Thu, 7 Nov 2019 19:42:45 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0190.hostedemail.com [216.40.44.190]) by kanga.kvack.org (Postfix) with ESMTP id 537C86B0005 for ; Thu, 7 Nov 2019 19:42:45 -0500 (EST) Received: from smtpin05.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with SMTP id 1B4BA499607 for ; Fri, 8 Nov 2019 00:42:45 +0000 (UTC) X-FDA: 76131259890.05.drop18_6f3b6ac5e3d5e X-HE-Tag: drop18_6f3b6ac5e3d5e X-Filterd-Recvd-Size: 6366 Received: from mga03.intel.com (mga03.intel.com [134.134.136.65]) by imf37.hostedemail.com (Postfix) with ESMTP for ; Fri, 8 Nov 2019 00:42:44 +0000 (UTC) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga007.jf.intel.com ([10.7.209.58]) by orsmga103.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 07 Nov 2019 16:42:39 -0800 X-IronPort-AV: E=Sophos;i="5.68,279,1569308400"; d="scan'208";a="193007308" Received: from ahduyck-desk1.jf.intel.com ([10.7.198.76]) by orsmga007-auth.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 07 Nov 2019 16:42:38 -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: Thu, 07 Nov 2019 16:42:38 -0800 In-Reply-To: <4cf64ff9-b099-d50a-5c08-9a8f3a2f52bf@redhat.com> References: <20191106121605.GH8314@dhcp22.suse.cz> <20191106165416.GO8314@dhcp22.suse.cz> <4cf64ff9-b099-d50a-5c08-9a8f3a2f52bf@redhat.com> 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 23:43 +0100, David Hildenbrand wrote: [...] > > > > Yes, if we end up finding out that there is real value in your approach, > > > nothing speaks against considering it. But please don't try to hurry and > > > push your series in that way. Please give everybody to time to evaluate. > > > > I would love to argue this patch set on the merits. However I really don't > > feel like I am getting a fair comparison here, at least from you. Every > > other reply on the thread seems to be from you trying to reinforce any > > criticism and taking the opportunity to mention that there is another > > solution out there. It is fine to fight for your own idea, but at least > > "for your own idea" - are you saying Nitesh's approach is my idea? I > hope not, otherwise I would get credit for Rik's and Nitesh's work by > simply providing review comments. Sorry, I was using "your" in the collective sense. I meant Nitesh, Rik, MST, yourself, and any other folks are working on the bitmap approach. > Of course it is okay to fight for your own idea. > > > let me reply to the criticisms of my own patchset before you pile on. I > > Me (+ Michal): Are these core buddy changes really wanted and required. > Can we evaluate the alternatives properly. (Michal even proposed > something very similar to Nitesh's approach before even looking into it) That is part of my frustration. Before I even had a chance to explain the situation you had already jumped in throwing a "I second that" into the discussion and insisting on comparisons against Nitesh's patch set which I have already provided. Nitesh's most recent patch set caused a kernel panic, and when I fixed that then it is over 30% worse performance wise than my patch set, and then when Nitesh restricted the order to MAX_ORDER - 1 and added some logic to check the buddy before taking the lock then it finally became comparable. > You: Please take my patch set, it is better than the alternatives > because of X, for X in {RFC quality, sparse zones, locking internals, > current performance differences} I should have replied to Michal's original question and simply stated that Mel had not replied to the patches in the last month and a half. I half suspect that is the reason for Andrew applying it. It put some pressure on others to provide review feedback, which if nothing else I am grateful for. You had inserted the need to compare it against Nitesh's patch set. Which based on Nitesh's email is likely going to be a little while since he cannot give me an ETA. > And all I am requesting is that we do the evaluation, discuss if there > are really no alternatives, and sort out fundamental issues with > external tracking. > > Michal asked the very same question again at the beginning of this > thread: "Is there really a consensus" Yes, but he also said he is not nacking the patch. It seemed like he is deferring to Mel on this so I will try to work with Mel to address his concerns since he had some feedback that I can act on. I'll address the comments Mel provided and be submitting a v14 sometime soon. > Reading the replies, "no". I get that you think the bitmap approach is the best approach, but the fact is it is still invasive, just to different parts of the mm subsystem. I would argue that one of my concerns about the hotplug and sparse handling is that by skipping those for now is essentially hiding what is likely to be some invasive code, likely not too different from what I had to deal with with compaction. At this point he adds more data to the zone struct than my changes, and I suspect as he progresses that may increase further. I do not think it is fair to hold up review and acceptance of this patch set for performance comparisons with a patch set with no definite ETA. Ideally we should be able to review and provide feedback on this patch set on its own. Since Nitesh's code is in part based on my virio-balloon code anyway it would make more sense to replace my code eventually if/when he comes up with a better solution. One thing I can do is make sure that my code is as non-intrusive as possible so that if/when that time comes reverting it would not be too difficult.