Received: by 2002:a05:6a10:16a7:0:0:0:0 with SMTP id gp39csp1425854pxb; Fri, 20 Nov 2020 09:09:32 -0800 (PST) X-Google-Smtp-Source: ABdhPJzkxkWs9+8YGTSRxDpSKowAQ6r4nrS6tCo8hpYKNe68GQuV8MjbEjm7e3Tr78dpRQFBrROD X-Received: by 2002:a50:a1c6:: with SMTP id 64mr11141658edk.156.1605892172118; Fri, 20 Nov 2020 09:09:32 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1605892172; cv=none; d=google.com; s=arc-20160816; b=uu2i5KUZ6TrUfhahJbcykBO3pMOhoOO2jl1oSw6jYLpQARwzIdeDF6ThxIPvSd/K2V bmG7xzjxnfO4A8D7Gmi50UxYgUroGtX5Hp/PLvgBseZ3MaWyENqUcdh3taqSVNH4EbU3 7QSd11rQ6dnGt5qXifyOlyykvWNFZgozBKiNQm5duXWHbj9QCee6xKAJjAI0KtXzS1FS oyIBkitfeOgcrHP4THPhGWW7gB7Nz2IPRZFbiGSdOCYhVmU066B7S4/yUb/eBYycHGn6 DD59RFXI0yhdS7FjrC7FE3wEVif03tNYbH0bL4EiHSjgiQXdPdK0K3oS3Ly0cC5SsBgA Jq4Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-language:content-transfer-encoding :in-reply-to:mime-version:user-agent:date:message-id:organization :from:references:cc:to:subject:dkim-signature; bh=+fDQVmfFKeAGKLRGbsrcZpScq4bc7Sw4oihjxYlBdLs=; b=hX0Zpd4nxUcTSjiOchShqQgZ7UFab8fhpHfq5ZPeACJTU+ajr5v0vPNJeBqFUssFF3 OKc4TDMK8YGAc2u03zcHroEwAFzhHbDnSZPnXJOAjCCibk6XCY67Oe5lIEn/MRuxbxtR M27cwqhKUX85V72If6f2q4Fi43ta82r7xqtUSICB/ox1jy/RvSDSeFwNU/i82i8OCKar lKfSFc6cCFQ6kB/Yl4j2lWA1+DTw8WvB7mKIKcVvQhm1mZRAAwGBYJMdyPmhTcMDFV+J Y3Sp8MgYYXfRSr6CzSYMuslM/wxmepT9p7xhPe+DtFIqK3W0OCSPLZFgrBEwSFobICzp 0ErQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=eTlaPESw; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id d22si1916453ejz.82.2020.11.20.09.09.02; Fri, 20 Nov 2020 09:09:32 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=eTlaPESw; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730245AbgKTREc (ORCPT + 99 others); Fri, 20 Nov 2020 12:04:32 -0500 Received: from us-smtp-delivery-124.mimecast.com ([63.128.21.124]:26399 "EHLO us-smtp-delivery-124.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728771AbgKTREb (ORCPT ); Fri, 20 Nov 2020 12:04:31 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1605891870; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=+fDQVmfFKeAGKLRGbsrcZpScq4bc7Sw4oihjxYlBdLs=; b=eTlaPESwXU6G90UsLc4CyS5sb9sNrPPQYqTED7puhmDlvcKpUKis9j2eV9p72LI4zzBYBy chVDMhTEWMeSqBbY1rLEG5/hmS4vYqtab43YgqirrcA1VvZcuF+GgZDjU+IQ6rkqmTw/gw Ig+vpL2pPwOCOzMFIVuT5nRaNXRH0jM= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-428-q6tZPtKfNw-l-ZXQ9ou6cA-1; Fri, 20 Nov 2020 12:04:28 -0500 X-MC-Unique: q6tZPtKfNw-l-ZXQ9ou6cA-1 Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 43985CE647; Fri, 20 Nov 2020 17:04:26 +0000 (UTC) Received: from llong.remote.csb (ovpn-118-157.rdu2.redhat.com [10.10.118.157]) by smtp.corp.redhat.com (Postfix) with ESMTP id 6E4201F0; Fri, 20 Nov 2020 17:04:24 +0000 (UTC) Subject: Re: [RFC PATCH 5/5] locking/rwsem: Remove reader optimistic spinning To: David Laight , Davidlohr Bueso Cc: Peter Zijlstra , Ingo Molnar , Will Deacon , "linux-kernel@vger.kernel.org" , Phil Auld References: <20201118030429.23017-1-longman@redhat.com> <20201118030429.23017-6-longman@redhat.com> <20201118053556.3fmmtat7upv6dtvd@linux-p48b.lan> <5fe76531782f4a8492b341d5f381147b@AcuMS.aculab.com> From: Waiman Long Organization: Red Hat Message-ID: <68d07068-ff31-26b5-f90d-7ea8b4ee2389@redhat.com> Date: Fri, 20 Nov 2020 12:04:24 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 In-Reply-To: <5fe76531782f4a8492b341d5f381147b@AcuMS.aculab.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-Scanned-By: MIMEDefang 2.79 on 10.5.11.11 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 11/20/20 8:11 AM, David Laight wrote: > From: Waiman Long >> Sent: 19 November 2020 18:40 > ... >> My own testing also show not too much performance difference when >> removing reader spinning except in the lightly loaded cases. > I'm confused. > > I got massive performance improvements from changing a driver > we have to use mutex instead of the old semaphores (the driver > was written a long time ago). > > While these weren't 'rw' the same issue will apply. > > The problem was that the semaphore/mutex was typically only held over > a few instructions (eg to add an item to a list). > But with semaphore if you got contention the process always slept. > OTOH mutex spin 'for a while' before sleeping so the code rarely slept. > > So I really expect that readers need to spin (for a while) if > a rwsem (etc) is locked for writing. > > Clearly you really need a CBU (Crystal Ball Unit) to work out > whether to spin or not. That is the hard part. For short critical section and not many readers around, making the readers spin will likely improve performance. On the other hand, if the critical section is long with many readers, make readers sleep and then wake them all up at once can have better performance. There is no one-size-fit-all solution here. Cheers, Longman