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=-0.8 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, 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 88932C433E0 for ; Wed, 8 Jul 2020 05:11:01 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 6192020720 for ; Wed, 8 Jul 2020 05:11:01 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="M8TEn2dP" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729687AbgGHFK7 (ORCPT ); Wed, 8 Jul 2020 01:10:59 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:47786 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726174AbgGHFK6 (ORCPT ); Wed, 8 Jul 2020 01:10:58 -0400 Received: from mail-pl1-x644.google.com (mail-pl1-x644.google.com [IPv6:2607:f8b0:4864:20::644]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 8EAC0C061755; Tue, 7 Jul 2020 22:10:58 -0700 (PDT) Received: by mail-pl1-x644.google.com with SMTP id x11so17674845plo.7; Tue, 07 Jul 2020 22:10:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:subject:to:cc:references:in-reply-to:mime-version :message-id:content-transfer-encoding; bh=NBE822KLqldc4RgjTMLNTL7g5oeVKxCy90pB/bhnbqA=; b=M8TEn2dPCMOvBZET4JnaMDMy0lYBY2dVPXjJw8C+E1TwnoBBTuk66pgPu2fJqXKVx1 B5vvUPxm8LxCIC+/4HpDyj9eQK+FH+k8I9aySXAuKaiX/IyWQBl6c9oSucY0pJSrHdhk kmKB9L6ekk6XeywFS7Hoy/JAxeOTezXXqTtHJtI9+cpy4/BmerCtU+RNLW1bt+52PMrU Pk0YR8Vd5fowCPr/XR1VDl6eRw8K/yg3l2NMayfyGThwcRjmydMPd/jZW4d43k68o1N9 VVe106DV3DoJXbOl4exlvOx0GiUCrvhWLD74gWkyw6keF+43d7HBt78+En6/6Yio7WIE LqLw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:subject:to:cc:references:in-reply-to :mime-version:message-id:content-transfer-encoding; bh=NBE822KLqldc4RgjTMLNTL7g5oeVKxCy90pB/bhnbqA=; b=JhmWHhxHnTLLZqVh6MLdbLZsUoEJqjkKkaYICO3X93xJBE+tRD7Rb3a13X5ey4OrdX LiglmSeb6/XlTOfZQNEm26bGG4cNQsdT4+aP8DulXL0SR5ORTqXKPbqZU+oVWsbJ5/FN +QzwB+EYF9q2H7aloJxyHn3bk66GdzmbnK48Ii/3VuoCYjruY8/Nr+82tvhwtVYSvzxZ VKA01lPrOWuasxEtHVapcjvjWmPq48LxPvfGb8pyONzcsJLZ4J4SIv/8bloAIbqzs5wp rDXMFG7ePl2gv91unAPKDS8eQFjLXPxak2PSn53R3eRryR02oaR40cWUt4BAaPDZ+Ut0 eo7Q== X-Gm-Message-State: AOAM531jaDN9B+Q7f1Hgn0qGmVgOFAQ1K6907Jrc/UE0qek2wnaGIe5j as1grOCoqzduZASsaFgKVcI= X-Google-Smtp-Source: ABdhPJy7irHmoUu0ynDnJY978dkucESYFNMabuBQ/Z2GkOluE+v9BuscHayaBiw3xLfuRm15lUcw4A== X-Received: by 2002:a17:902:b114:: with SMTP id q20mr23771251plr.266.1594185058097; Tue, 07 Jul 2020 22:10:58 -0700 (PDT) Received: from localhost (61-68-186-125.tpgi.com.au. [61.68.186.125]) by smtp.gmail.com with ESMTPSA id m20sm25080630pfk.52.2020.07.07.22.10.56 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 07 Jul 2020 22:10:57 -0700 (PDT) Date: Wed, 08 Jul 2020 15:10:52 +1000 From: Nicholas Piggin Subject: Re: [PATCH v3 0/6] powerpc: queued spinlocks and rwlocks To: linuxppc-dev@lists.ozlabs.org, Waiman Long Cc: Anton Blanchard , Boqun Feng , kvm-ppc@vger.kernel.org, linux-arch@vger.kernel.org, linux-kernel@vger.kernel.org, Ingo Molnar , Peter Zijlstra , virtualization@lists.linux-foundation.org, Will Deacon References: <20200706043540.1563616-1-npiggin@gmail.com> <24f75d2c-60cd-2766-4aab-1a3b1c80646e@redhat.com> <1594101082.hfq9x5yact.astroid@bobo.none> In-Reply-To: MIME-Version: 1.0 Message-Id: <1594184204.ncuq7vstsz.astroid@bobo.none> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Excerpts from Waiman Long's message of July 8, 2020 1:33 pm: > On 7/7/20 1:57 AM, Nicholas Piggin wrote: >> Yes, powerpc could certainly get more performance out of the slow >> paths, and then there are a few parameters to tune. >> >> We don't have a good alternate patching for function calls yet, but >> that would be something to do for native vs pv. >> >> And then there seem to be one or two tunable parameters we could >> experiment with. >> >> The paravirt locks may need a bit more tuning. Some simple testing >> under KVM shows we might be a bit slower in some cases. Whether this >> is fairness or something else I'm not sure. The current simple pv >> spinlock code can do a directed yield to the lock holder CPU, whereas >> the pv qspl here just does a general yield. I think we might actually >> be able to change that to also support directed yield. Though I'm >> not sure if this is actually the cause of the slowdown yet. >=20 > Regarding the paravirt lock, I have taken a further look into the=20 > current PPC spinlock code. There is an equivalent of pv_wait() but no=20 > pv_kick(). Maybe PPC doesn't really need that. So powerpc has two types of wait, either undirected "all processors" or=20 directed to a specific processor which has been preempted by the=20 hypervisor. The simple spinlock code does a directed wait, because it knows the CPU=20 which is holding the lock. In this case, there is a sequence that is=20 used to ensure we don't wait if the condition has become true, and the target CPU does not need to kick the waiter it will happen automatically (see splpar_spin_yield). This is preferable because we only wait as=20 needed and don't require the kick operation. The pv spinlock code I did uses the undirected wait, because we don't know the CPU number which we are waiting on. This is undesirable because=20 it's higher overhead and the wait is not so accurate. I think perhaps we could change things so we wait on the correct CPU=20 when queued, which might be good enough (we could also put the lock owner CPU in the spinlock word, if we add another format). > Attached are two=20 > additional qspinlock patches that adds a CONFIG_PARAVIRT_QSPINLOCKS_LITE=20 > option to not require pv_kick(). There is also a fixup patch to be=20 > applied after your patchset. >=20 > I don't have access to a PPC LPAR with shared processor at the moment,=20 > so I can't test the performance of the paravirt code. Would you mind=20 > adding my patches and do some performance test on your end to see if it=20 > gives better result? Great, I'll do some tests. Any suggestions for what to try? Thanks, Nick