Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) client-ip=2620:137:e000::1:18;
Date:   Wed, 9 Feb 2022 13:08:24 -0800
From:   Davidlohr Bueso <dave@stgolabs.net>
To:     Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Cc:     linux-kernel@vger.kernel.org,
        Peter Zijlstra <peterz@infradead.org>,
        Waiman Long <longman@redhat.com>,
        Ingo Molnar <mingo@redhat.com>, Will Deacon <will@kernel.org>,
        Thomas Gleixner <tglx@linutronix.de>
Subject: Re: [PATCH REPOST] locking/local_lock: Make the empty local_lock_*()
 function a macro.
Message-ID: <20220209210824.wwsq63z4o6a6ei7a@offworld>
References: <YgKjciR60fZft2l4@linutronix.de>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Disposition: inline
In-Reply-To: <YgKjciR60fZft2l4@linutronix.de>
User-Agent: NeoMutt/20211029
Precedence: bulk

On Tue, 08 Feb 2022, Sebastian Andrzej Siewior wrote:

>It has been said that local_lock() does not add any overhead compared to
>preempt_disable() in a !LOCKDEP configuration. A micro benchmark showed
>an unexpected result which can be reduced to the fact that local_lock()
>was not entirely optimized away.
>In the !LOCKDEP configuration local_lock_acquire() is an empty static
>inline function. On x86 the this_cpu_ptr() argument of that function is
>fully evaluated leading to an additional mov+add instructions which are
>not needed and not used.
>
>Replace the static inline function with a macro. The typecheck() macro
>ensures that the argument is of proper type while the resulting
>disassembly shows no traces of this_cpu_ptr().
>
>Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
>Reviewed-by: Waiman Long <longman@redhat.com>

Reviewed-by: Davidlohr Bueso <dbueso@suse.de>