From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S966535AbdACWI0 (ORCPT ); Tue, 3 Jan 2017 17:08:26 -0500 Received: from mx1.redhat.com ([209.132.183.28]:53472 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757209AbdACWIR (ORCPT ); Tue, 3 Jan 2017 17:08:17 -0500 Subject: Re: [PATCH v2] locking/pvqspinlock: Relax cmpxchg's to improve performance on some archs To: Peter Zijlstra References: <1482697561-23848-1-git-send-email-longman@redhat.com> <20170103161836.GY3107@twins.programming.kicks-ass.net> Cc: Ingo Molnar , linux-kernel@vger.kernel.org, Pan Xinhui , Boqun Feng From: Waiman Long Organization: Red Hat Message-ID: Date: Tue, 3 Jan 2017 17:07:54 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <20170103161836.GY3107@twins.programming.kicks-ass.net> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.29]); Tue, 03 Jan 2017 22:07:55 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 01/03/2017 11:18 AM, Peter Zijlstra wrote: > On Sun, Dec 25, 2016 at 03:26:01PM -0500, Waiman Long wrote: >> A number of cmpxchg calls in qspinlock_paravirt.h were replaced by more >> relaxed versions to improve performance on architectures that use LL/SC. > Claim without numbers ;-) Well it is hard to produce actual numbers here as I don't have the setup to gather data. >> All the locking related cmpxchg's are replaced with the _acquire >> variants: >> - pv_queued_spin_steal_lock() >> - trylock_clear_pending() > So these seem to make sense in that they're in 'fast' paths.. > >> The cmpxchg's related to hashing are replaced by either by the _release >> or the _relaxed variants. See the inline comment for details. > > But these not so much, we're going to put the vcpu to sleep, why does it > make sense to 'optimize' the wait/kick stuff? I haven't thought too much about fast/slow paths when I was making the patch. You are right that we properly don't need to do that for the slowpath cases. I can modify the patch to do just the fast patch change. Cheers, Longman