Received: by 2002:a05:6a10:16a7:0:0:0:0 with SMTP id gp39csp1947712pxb; Sat, 21 Nov 2020 03:52:15 -0800 (PST) X-Google-Smtp-Source: ABdhPJzZnNm77SYWaxoU0K5/T3XVsXjyPau/M9WNnFEjjqSYGOjwym40Rf6oEDiUu7lYj7SmM+1t X-Received: by 2002:a17:906:3153:: with SMTP id e19mr10489932eje.17.1605959535045; Sat, 21 Nov 2020 03:52:15 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1605959535; cv=none; d=google.com; s=arc-20160816; b=WUzNu9JZxzfvc7u7UqYEeY7MCUJldUdtRuldI3xC/LYxZtnEsvMbg8V3+YYyJT165/ GRYuBMZDRrqR01wZaeFOS9RR1gf1JQUJxtqdKX44tSyCEw4Pg9Y64vqmBJUNuGMRmA3Z wzeDoGOQh3mQ5SUBYhbna3XMtSW2E7qqeUkD3wA7I7IKLS42GCLmUe+3kK4uc1SijQOT 8pB494XLjP+CX9l9B1s5C3ypKlS/pbj3sej2Fq7voEVGfWhJt5rvyRmm2TsIfUoHhoOT fn5OQBTGmZHEgD319BzVcb3xZivEKT603RkMQVedS6obBFJfwK7+siHjKKatONs1gxs4 D/mA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:content-language :mime-version:accept-language:in-reply-to:references:message-id:date :thread-index:thread-topic:subject:cc:to:from; bh=q9mW3wk/+HNUAkag9HQhxiJDp6gHOYuiGXxdq3JaLuE=; b=EQSGVQFY4Wwqha+0dNoiyUKlzU/2dNuH6uxi8QTccD3VkUA6KtMa6ev2j8m56GI09s qIAiKoOkQ/w2uHcAbeBl9fgRHxG3yQiYm95LV4WfBMzX5aP8GgeZbER/DkFw9Qa+LaoO Dukgc7aRG4YMx5S2JB9LcASc+nvJbKWQRrzYZ/wiUOIaehNw/oGgRb6NprmrD2OUxxbF /JYmnApkZWPBysVIONYBerk7SDgZS8f34vcfNPyeHBbpoP+8qiYyXAjP/tQjUiEE4Tav CBl5HOxm4OaMnKIGC9dHIvlACAf5qdwn6FONW0q3L0fCQ+QmIZkEPh4iCXtV8tk+iYQW LR9w== ARC-Authentication-Results: i=1; mx.google.com; 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=fail (p=NONE sp=NONE dis=NONE) header.from=aculab.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id 33si3432538edq.243.2020.11.21.03.51.52; Sat, 21 Nov 2020 03:52:15 -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; 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=fail (p=NONE sp=NONE dis=NONE) header.from=aculab.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727514AbgKULu3 convert rfc822-to-8bit (ORCPT + 99 others); Sat, 21 Nov 2020 06:50:29 -0500 Received: from eu-smtp-delivery-151.mimecast.com ([185.58.86.151]:39614 "EHLO eu-smtp-delivery-151.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727337AbgKULu3 (ORCPT ); Sat, 21 Nov 2020 06:50:29 -0500 Received: from AcuMS.aculab.com (156.67.243.126 [156.67.243.126]) (Using TLS) by relay.mimecast.com with ESMTP id uk-mta-45-zOLMDCtGMdWjyngmXZIzpw-1; Sat, 21 Nov 2020 11:50:23 +0000 X-MC-Unique: zOLMDCtGMdWjyngmXZIzpw-1 Received: from AcuMS.Aculab.com (fd9f:af1c:a25b:0:43c:695e:880f:8750) by AcuMS.aculab.com (fd9f:af1c:a25b:0:43c:695e:880f:8750) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Sat, 21 Nov 2020 11:50:23 +0000 Received: from AcuMS.Aculab.com ([fe80::43c:695e:880f:8750]) by AcuMS.aculab.com ([fe80::43c:695e:880f:8750%12]) with mapi id 15.00.1347.000; Sat, 21 Nov 2020 11:50:22 +0000 From: David Laight To: 'Davidlohr Bueso' CC: 'Waiman Long' , Peter Zijlstra , Ingo Molnar , Will Deacon , "linux-kernel@vger.kernel.org" , Phil Auld Subject: RE: [RFC PATCH 5/5] locking/rwsem: Remove reader optimistic spinning Thread-Topic: [RFC PATCH 5/5] locking/rwsem: Remove reader optimistic spinning Thread-Index: AQHWvqN0O6hwIV/IOUmlkB4qEdd62KnQ/N3QgACQ0wCAAOypEA== Date: Sat, 21 Nov 2020 11:50:22 +0000 Message-ID: <45f36a7545c84b62b49aaff95f28a49a@AcuMS.aculab.com> References: <20201118030429.23017-1-longman@redhat.com> <20201118030429.23017-6-longman@redhat.com> <20201118053556.3fmmtat7upv6dtvd@linux-p48b.lan> <5fe76531782f4a8492b341d5f381147b@AcuMS.aculab.com> <20201120213828.n7f23qy75hduommo@linux-p48b.lan> In-Reply-To: <20201120213828.n7f23qy75hduommo@linux-p48b.lan> Accept-Language: en-GB, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.202.205.107] MIME-Version: 1.0 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=C51A453 smtp.mailfrom=david.laight@aculab.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: aculab.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8BIT Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Davidlohr Bueso > Sent: 20 November 2020 21:38 > > On Fri, 20 Nov 2020, David Laight wrote: > >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. > > The caveat here is if you are using trylock/unlock from irq, which > is the only reason why regular semaphores are still around today. If > not, indeed a mutex is better. Unless you want to timeout the lock request. Timeouts are particularly useful in code paths that might run after an 'oops' or other deadlock. Typically for reporting status information. You get to choose whether to error the status request or carry on knowing that the data is unlikely to change. David - Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK Registration No: 1397386 (Wales)