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 91081C2D0CD for ; Tue, 17 Dec 2019 18:24:49 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 56AE6206B7 for ; Tue, 17 Dec 2019 18:24:49 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 56AE6206B7 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 F10118E009C; Tue, 17 Dec 2019 13:24:48 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id EC0F58E0079; Tue, 17 Dec 2019 13:24:48 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id DD6B18E009C; Tue, 17 Dec 2019 13:24:48 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0048.hostedemail.com [216.40.44.48]) by kanga.kvack.org (Postfix) with ESMTP id C77E38E0079 for ; Tue, 17 Dec 2019 13:24:48 -0500 (EST) Received: from smtpin17.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with SMTP id 59DB0180AD807 for ; Tue, 17 Dec 2019 18:24:48 +0000 (UTC) X-FDA: 76275459456.17.patch89_cc2634c1d723 X-HE-Tag: patch89_cc2634c1d723 X-Filterd-Recvd-Size: 4062 Received: from mga07.intel.com (mga07.intel.com [134.134.136.100]) by imf14.hostedemail.com (Postfix) with ESMTP for ; Tue, 17 Dec 2019 18:24:47 +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 orsmga105.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 17 Dec 2019 10:24:46 -0800 X-IronPort-AV: E=Sophos;i="5.69,326,1571727600"; d="scan'208";a="209789792" 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; 17 Dec 2019 10:24:46 -0800 Message-ID: <1a6e4646f570bf193924e099557841eb6e77a80d.camel@linux.intel.com> Subject: Re: [PATCH v15 3/7] mm: Add function __putback_isolated_page From: Alexander Duyck To: David Hildenbrand , Alexander Duyck , kvm@vger.kernel.org, mst@redhat.com, linux-kernel@vger.kernel.org, willy@infradead.org, mhocko@kernel.org, linux-mm@kvack.org, akpm@linux-foundation.org, mgorman@techsingularity.net, vbabka@suse.cz Cc: yang.zhang.wz@gmail.com, nitesh@redhat.com, konrad.wilk@oracle.com, pagupta@redhat.com, riel@surriel.com, lcapitulino@redhat.com, dave.hansen@intel.com, wei.w.wang@intel.com, aarcange@redhat.com, pbonzini@redhat.com, dan.j.williams@intel.com, osalvador@suse.de Date: Tue, 17 Dec 2019 10:24:46 -0800 In-Reply-To: <1fc997cf-b1f3-3fe6-b699-efb9ef7f17cf@redhat.com> References: <20191205161928.19548.41654.stgit@localhost.localdomain> <20191205162230.19548.70198.stgit@localhost.localdomain> <9eb9173278370dd604c4cefd30ed10be36600854.camel@linux.intel.com> <8a4b0337-0bad-2978-32e8-6f90c7365f00@redhat.com> <753e2991e3e632b9c179c45197bfb05669625e9a.camel@linux.intel.com> <1fc997cf-b1f3-3fe6-b699-efb9ef7f17cf@redhat.com> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.32.5 (3.32.5-1.fc30) 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 Tue, 2019-12-17 at 18:24 +0100, David Hildenbrand wrote: > >>> Also there are some scenarios where __page_to_pfn is not that simple a > > > > call with us having to get the node ID so we can find the pgdat structure > > > > to perform the calculation. I'm not sure the compiler would be ble to > > > > figure out that the result is the same for both calls, so it is better to > > > > make it explicit. > > > > > > Only in case of CONFIG_SPARSEMEM we have to go via the section - but I > > > doubt this is really worth optimizing here. > > > > > > But yeah, I'm fine with this change, only "IMHO > > > get_pageblock_migratetype() would be nicer" :) > > > > Aren't most distros running with CONFIG_SPARSEMEM enabled? If that is the > > case why not optimize for it? > > Because I tend to dislike micro-optimizations without performance > numbers for code that is not on a hot path. But I mean in this case, as > you said, you need the pfn either way, so it's completely fine with. > > I do wonder, however, if you should just pass in the migratetype from > the caller. That would be even faster ;) The problem is page isolation. We can end up with a page being moved to an isolate pageblock while we aren't holding the zone lock, and as such we likely need to test it again anyway. So there isn't value in storing and reusing the value for cases like page reporting. In addition, the act of isolating the page can cause the migratetype to change as __isolate_free_page will attempt to change the migratetype to movable if it is one of the standard percpu types and we are pulling at least half a pageblock out. So storing the value before we isolate it would be problematic as well. Undoing page isolation is the exception to the issues pointed out above, but in that case we are overwriting the pageblock migratetype anyway so the cache lines involved should all be warm from having just set the value.