Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Date:   Sun, 8 Mar 2020 04:50:07 -0700
From:   Matthew Wilcox <willy@infradead.org>
To:     Andrew Morton <akpm@linux-foundation.org>
Cc:     mateusznosek0@gmail.com, linux-mm@kvack.org,
        linux-kernel@vger.kernel.org
Subject: Re: [RFC PATCH] mm/page_alloc.c: Micro-optimisation Remove
 unnecessary branch
Message-ID: <20200308115007.GE31215@bombadil.infradead.org>
References: <20200307225335.31300-1-mateusznosek0@gmail.com>
 <20200307151542.b14131037dc44a8edcb22cad@linux-foundation.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20200307151542.b14131037dc44a8edcb22cad@linux-foundation.org>
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Sat, Mar 07, 2020 at 03:15:42PM -0800, Andrew Morton wrote:
> On Sat,  7 Mar 2020 23:53:35 +0100 mateusznosek0@gmail.com wrote:
> > -	if (unlikely(ac.nodemask != nodemask))
> > -		ac.nodemask = nodemask;
> > +	ac.nodemask = nodemask;
> 
> This will now unconditionally dirty the ac.nodemask cacheline, which
> means that cacheline will need to be written back.  If it is truly
> unlikely that the write was needed then the thinking goes that the
> test-and-branch is worthwhile, by saving on memory traffic.
> 
> At least, I assume that's why the code is the way it is.

The line immediately before this hunk is:

        ac.spread_dirty_pages = false;

ac is on-stack and is only 32 bytes.  I don't see a reason not to do this.

Reviewed-by: Matthew Wilcox (Oracle) <willy@infradead.org>