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=-5.9 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,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 96091C48BDF for ; Tue, 15 Jun 2021 18:52:58 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 348D3611EE for ; Tue, 15 Jun 2021 18:52:58 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 348D3611EE Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=redhat.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id BFCD06B0070; Tue, 15 Jun 2021 14:52:57 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id BD4106B0071; Tue, 15 Jun 2021 14:52:57 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A741A6B0072; Tue, 15 Jun 2021 14:52:57 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0244.hostedemail.com [216.40.44.244]) by kanga.kvack.org (Postfix) with ESMTP id 788A06B0070 for ; Tue, 15 Jun 2021 14:52:57 -0400 (EDT) Received: from smtpin23.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id 1D9618249980 for ; Tue, 15 Jun 2021 18:52:57 +0000 (UTC) X-FDA: 78256855194.23.FAFD10B Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [216.205.24.124]) by imf20.hostedemail.com (Postfix) with ESMTP id 71D52F2 for ; Tue, 15 Jun 2021 18:52:43 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1623783175; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=9nA288JO8PSyw9mKU3u+nzowGkx8Yk/ykJ4RqSFR/wM=; b=WJ6Kf8z7A06uZs+KuIYJcTktYVQiYSjW2+Ejsi1OVa3ZtyiHRCy3IZA+Bj6z8mCfTqtCLX PiRZ2Tr+xy8VpdmGjEW0UtEU5ClYtP1bE94PP41mCu2eEr5t8e6NiLnrubkxZf6EITaWhQ FLfqfFX5j10WNj0mx72T/c8eS2fHdZU= Received: from mail-qt1-f198.google.com (mail-qt1-f198.google.com [209.85.160.198]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-165-0A7TzqcJOuWYt_u2lGv6Uw-1; Tue, 15 Jun 2021 14:52:51 -0400 X-MC-Unique: 0A7TzqcJOuWYt_u2lGv6Uw-1 Received: by mail-qt1-f198.google.com with SMTP id 62-20020aed30440000b029024cabef375cso6884798qte.17 for ; Tue, 15 Jun 2021 11:52:51 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=9nA288JO8PSyw9mKU3u+nzowGkx8Yk/ykJ4RqSFR/wM=; b=eNwZarOjbwyv0/IB7lXvrhkmMNI213bMlftyoM8w2JIQoDA7DwKQsoKEq30MHmNScj j07EhbREvR3Usbv/Y3NgNkmLwWf3Z6BGwX9uUpqIyMCP4QCxBouaEanxQDZU1rJdHgyt uF6BSqCm+A2sTh0K5Mea9XVLlro2UqbnQIjvARurLwdwIegnEUtrwo/nnSka/pPpaa2B QfoYNjP74ORhUu56gAzPPcIKCyZbycar+ae7fjxMMPdkPqsuQP4AFItiVecZCB8tRLeK Qk2tDcNoze2+WrHxekWwyQkwT2Jt/l9f+YdHvfhLGlw+FsQ+D0IkpkQMelzsEnhqUBIJ VMZg== X-Gm-Message-State: AOAM530pOdH/nUcKuRfiR3FnJglHS1YtOUMAmt4KGkuvl2QJiUlrIVcR 0RGQdFAqTS8HnYazKG6aJpddwNDMPfDZyp9zLyYaDwSspbwtyQCx3JfuiJO7x5b79Usyfksv/C0 DnEPt1fiZa5w= X-Received: by 2002:a37:a513:: with SMTP id o19mr1107717qke.470.1623783171244; Tue, 15 Jun 2021 11:52:51 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxQ99edx7nfSWHifVKkoU4UY7i8EkmYP4SjCPEvUcoZGG0M/SSzwhh7wbXC8NWaWSNw3zYuug== X-Received: by 2002:a37:a513:: with SMTP id o19mr1107699qke.470.1623783171024; Tue, 15 Jun 2021 11:52:51 -0700 (PDT) Received: from t490s (bras-base-toroon474qw-grc-65-184-144-111-238.dsl.bell.ca. [184.144.111.238]) by smtp.gmail.com with ESMTPSA id q16sm12843398qkq.121.2021.06.15.11.52.49 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 15 Jun 2021 11:52:50 -0700 (PDT) Date: Tue, 15 Jun 2021 14:52:49 -0400 From: Peter Xu To: Feng Tang Cc: Jason Gunthorpe , linux-mm@kvack.org, Andrew Morton , Linus Torvalds , kernel test robot , John Hubbard , linux-kernel@vger.kernel.org, lkp@lists.01.org Subject: Re: [PATCH] mm: relocate 'write_protect_seq' in struct mm_struct Message-ID: References: <1623376482-92265-1-git-send-email-feng.tang@intel.com> <20210611170917.GW1002214@nvidia.com> <20210614032738.GA72794@shbuild999.sh.intel.com> <20210615011102.GA38780@shbuild999.sh.intel.com> MIME-Version: 1.0 In-Reply-To: <20210615011102.GA38780@shbuild999.sh.intel.com> X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Disposition: inline X-Rspamd-Server: rspam01 X-Rspamd-Queue-Id: 71D52F2 Authentication-Results: imf20.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=WJ6Kf8z7; spf=none (imf20.hostedemail.com: domain of peterx@redhat.com has no SPF policy when checking 216.205.24.124) smtp.mailfrom=peterx@redhat.com; dmarc=pass (policy=none) header.from=redhat.com X-Stat-Signature: w97jey8yr5m95jnrfkrunac3nma9jyww X-HE-Tag: 1623783163-651195 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000098, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Tue, Jun 15, 2021 at 09:11:03AM +0800, Feng Tang wrote: > On Mon, Jun 14, 2021 at 11:27:39AM +0800, Feng Tang wrote: > > > > > > It seems Ok to me, but didn't we earlier add the has_pinned which > > > would have changed the layout too? Are we chasing performance delta's > > > nobody cares about? > > > > Good point! I checked my email folder for 0day's reports, and haven't > > found a report related with Peter's commit 008cfe4418b3 ("mm: Introduce > > mm_struct.has_pinned) which adds 'has_pinned' field. > > > > Will run the same test for it and report back. > > I run the same will-it-scale/mmap1 case for Peter's commit 008cfe4418b3 > and its parent commit, and there is no obvious performance diff: > > a1bffa48745afbb5 008cfe4418b3dbda2ff820cdd7b > ---------------- --------------------------- > > 344353 -0.4% 342929 will-it-scale.48.threads > 7173 -0.4% 7144 will-it-scale.per_thread_ops > > And from the pahole info for the 2 kernels, Peter's commit adds the > 'has_pinned' is put into an existing 4 bytes hole, so all other following > fields keep their alignment unchanged. Peter may do it purposely > considering the alignment. So no performance change is expected. Thanks for verifying this. I didn't do it on purpose at least for the initial version, but I do remember some comment to fill up that hole, so it may have got moved around. Also note that if nothing goes wrong, has_pinned will be gone in the next release with commit 3c0c4cda6d48 ("mm: gup: pack has_pinned in MMF_HAS_PINNED", 2021-05-26); it's in -mm-next but not reaching the main branch yet. So then I think the 4 bytes hole should come back to us again, with no perf loss either. What I'm thinking is whether we should move some important (and especially CONFIG_* irrelevant) fields at the top of the whole struct define, make sure they're most optimal for the common workload and make them static. Then there'll be less or no possibility some new field regress some common workload by accident. Not sure whether it makes sense to do so. Thanks, -- Peter Xu