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 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 19680C433F5 for ; Wed, 10 Nov 2021 17:09:12 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 2FA15610A2 for ; Wed, 10 Nov 2021 17:09:10 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 2FA15610A2 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=infradead.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvack.org Received: by kanga.kvack.org (Postfix) id B7D936B006C; Wed, 10 Nov 2021 12:09:09 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id B2DA06B0071; Wed, 10 Nov 2021 12:09:09 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A1CA76B0072; Wed, 10 Nov 2021 12:09:09 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0021.hostedemail.com [216.40.44.21]) by kanga.kvack.org (Postfix) with ESMTP id 939B06B006C for ; Wed, 10 Nov 2021 12:09:09 -0500 (EST) Received: from smtpin21.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 54EFD82275 for ; Wed, 10 Nov 2021 17:09:09 +0000 (UTC) X-FDA: 78793656018.21.2960219 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf01.hostedemail.com (Postfix) with ESMTP id 9DCC8508ECAC for ; Wed, 10 Nov 2021 17:08:54 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=5tEk+9IC6breLjA9Y5Hl6sjwzv1uZV7l5Zia416dvHg=; b=tQAMRO6Ez06RwurTHSr9s7avVV Tz9krQ6BkKZUbdoYUw58TAYyPIAXBXPEpFjZFeUjuRpqF0nAmlVoc4VvJZhnX3z5DWWqTkr155uH3 pGwKEh6yAei7elz7lT0hSlMkUoPpQPxj5MfciPpy59zFMD33a1QPQoDaXDH50B1uzrsh5pzzPT0bo rezzJ/abVwdShGbpYFqExlLNllY3IXs4kIHKUzqBxIjtoaBxikSCHPxXLQg+zMS/MVZWyMrui81vv V1Q6MygcWXzmK6Ag1HuU5ZwiwFL50nIxzM4zeZYX0OVbd+I4RapBK8+mRbBfa6QpyYhUC+n5rOVKF L/14o88g==; Received: from willy by casper.infradead.org with local (Exim 4.94.2 #2 (Red Hat Linux)) id 1mkqnK-0021ZL-Bk; Wed, 10 Nov 2021 16:49:54 +0000 Date: Wed, 10 Nov 2021 16:49:54 +0000 From: Matthew Wilcox To: David Hildenbrand Cc: Jason Gunthorpe , Qi Zheng , akpm@linux-foundation.org, tglx@linutronix.de, kirill.shutemov@linux.intel.com, mika.penttila@nextfour.com, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, songmuchun@bytedance.com, zhouchengming@bytedance.com Subject: Re: [PATCH v3 00/15] Free user PTE page table pages Message-ID: References: <20211110105428.32458-1-zhengqi.arch@bytedance.com> <20211110125601.GQ1740502@nvidia.com> <8d0bc258-58ba-52c5-2e0d-a588489f2572@redhat.com> <20211110143859.GS1740502@nvidia.com> <6ac9cc0d-7dea-0e19-51b3-625ec6561ac7@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6ac9cc0d-7dea-0e19-51b3-625ec6561ac7@redhat.com> X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: 9DCC8508ECAC X-Stat-Signature: sys3trm1711mb686tnmmh9tezrgnmco1 Authentication-Results: imf01.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=tQAMRO6E; dmarc=none; spf=none (imf01.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org X-HE-Tag: 1636564134-268021 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Wed, Nov 10, 2021 at 04:37:14PM +0100, David Hildenbrand wrote: > > I'd suggest to make this new lock a special rwsem which allows either > > concurrent read access OR concurrent PTL access, but not both. This > > I looked into such a lock recently in similar context and something like > that does not exist yet (and fairness will be challenging). You either > have a single reader or multiple writer. I'd be interested if someone > knows of something like that. We've talked about having such a lock before for filesystems which want to permit either many direct-IO accesses or many buffered-IO accesses, but want to exclude a mixture of direct-IO and buffered-IO. The name we came up with for such a lock was the red-blue lock. Either Team Red has the lock, or Team Blue has the lock (or it's free). Indicate free with velue zero, Team Red with positive numbers and Team Blue with negative numbers. If we need to indicate an opposing team is waiting for the semaphore, we can use a high bit (1 << 30) to indicate no new team members can acquire the lock. Not sure whether anybody ever coded it up.