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=-3.7 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED 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 6E239CA9EB6 for ; Wed, 23 Oct 2019 15:16:19 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 3801321872 for ; Wed, 23 Oct 2019 15:16:18 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 3801321872 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 F18E76B0006; Wed, 23 Oct 2019 11:16:17 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id EA2F06B0007; Wed, 23 Oct 2019 11:16:17 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D91666B0008; Wed, 23 Oct 2019 11:16:17 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0220.hostedemail.com [216.40.44.220]) by kanga.kvack.org (Postfix) with ESMTP id B74416B0006 for ; Wed, 23 Oct 2019 11:16:17 -0400 (EDT) Received: from smtpin27.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with SMTP id 498C3349B for ; Wed, 23 Oct 2019 15:16:17 +0000 (UTC) X-FDA: 76075400394.27.fan27_70d3bf1c28e3d X-HE-Tag: fan27_70d3bf1c28e3d X-Filterd-Recvd-Size: 4720 Received: from mga17.intel.com (mga17.intel.com [192.55.52.151]) by imf37.hostedemail.com (Postfix) with ESMTP for ; Wed, 23 Oct 2019 15:16:15 +0000 (UTC) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga005.jf.intel.com ([10.7.209.41]) by fmsmga107.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 23 Oct 2019 08:16:10 -0700 X-IronPort-AV: E=Sophos;i="5.68,221,1569308400"; d="scan'208";a="372905884" Received: from ahduyck-desk1.jf.intel.com ([10.7.198.76]) by orsmga005-auth.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 23 Oct 2019 08:16:07 -0700 Message-ID: <860dda361b6e0b94908d94beb0ad9f5519c8f2cf.camel@linux.intel.com> Subject: Re: [PATCH v12 2/6] mm: Use zone and order instead of free area in free_list manipulators 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: Wed, 23 Oct 2019 08:16:07 -0700 In-Reply-To: References: <20191022221223.17338.5860.stgit@localhost.localdomain> <20191022222805.17338.3243.stgit@localhost.localdomain> 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 Wed, 2019-10-23 at 10:26 +0200, David Hildenbrand wrote: > On 23.10.19 00:28, Alexander Duyck wrote: > > From: Alexander Duyck > > > > In order to enable the use of the zone from the list manipulator functions > > I will need access to the zone pointer. As it turns out most of the > > accessors were always just being directly passed &zone->free_area[order] > > anyway so it would make sense to just fold that into the function itself > > and pass the zone and order as arguments instead of the free area. > > > > In order to be able to reference the zone we need to move the declaration > > of the functions down so that we have the zone defined before we define the > > list manipulation functions. Since the functions are only used in the file > > mm/page_alloc.c we can just move them there to reduce noise in the header. > > > > Reviewed-by: Dan Williams > > Reviewed-by: David Hildenbrand > > Reviewed-by: Pankaj Gupta > > Signed-off-by: Alexander Duyck > > --- > > include/linux/mmzone.h | 32 ----------------------- > > mm/page_alloc.c | 67 +++++++++++++++++++++++++++++++++++------------- > > 2 files changed, 49 insertions(+), 50 deletions(-) > > Did you see > > https://lore.kernel.org/lkml/20191001152928.27008.8178.stgit@localhost.localdomain/T/#m4d2bc2f37bd7bdc3ae35c4f197905c275d0ad2f9 > > this time? > > And the difference to the old patch is only an empty line. > I saw the report. However I have not had much luck reproducing it in order to get root cause. Here are my results for linux-next 20191021 with that patch running page_fault2 over an average of 3 runs: Baseline: 3734692.00 This patch: 3739878.67 Also I am not so sure about these results as the same patch had passed previously before and instead it was patch 3 that was reported as having a -1.2% regression[1]. All I changed in response to that report was to add page_is_reported() which just wrapped the bit test for the reported flag in a #ifdef to avoid testing it for the blocks that were already #ifdef wrapped anyway. I am still trying to see if I can get access to a system that would be a better match for the one that reported the issue. My working theory is that maybe it requires a high core count per node to reproduce. Either that or it is some combination of the kernel being tested on and the patch is causing some loop to go out of alignment and become more expensive. I also included the page_fault2 results in my cover page as that seems to show a slight improvement with all of the patches applied. Thanks. - Alex [1]: https://lore.kernel.org/lkml/20190921152522.GU15734@shao2-debian/