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 kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 9A02DD2F7EF for ; Thu, 17 Oct 2024 06:46:45 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 1C0456B0083; Thu, 17 Oct 2024 02:46:45 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 171456B0088; Thu, 17 Oct 2024 02:46:45 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 037FC6B0089; Thu, 17 Oct 2024 02:46:44 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id D6DE16B0083 for ; Thu, 17 Oct 2024 02:46:44 -0400 (EDT) Received: from smtpin12.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id D867BA020D for ; Thu, 17 Oct 2024 06:46:24 +0000 (UTC) X-FDA: 82682160876.12.00BD24E Received: from mail-pl1-f176.google.com (mail-pl1-f176.google.com [209.85.214.176]) by imf07.hostedemail.com (Postfix) with ESMTP id 700D84000C for ; Thu, 17 Oct 2024 06:46:28 +0000 (UTC) Authentication-Results: imf07.hostedemail.com; dkim=pass header.d=bytedance.com header.s=google header.b=TQeZsPYY; spf=pass (imf07.hostedemail.com: domain of lizhe.67@bytedance.com designates 209.85.214.176 as permitted sender) smtp.mailfrom=lizhe.67@bytedance.com; dmarc=pass (policy=quarantine) header.from=bytedance.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1729147410; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=tv5UJ/Xk45I32p3AVak0iA4xEipZAR9oPUhdZra2dK0=; b=Ld7winM6V0/N46iRcJ+RVlwVRa1/Ugy1E1D+yTsYONJBjG6q6837eRwOn2KnZePzTPMkA5 9nClKtSsRw31D7BAYZK/cFtJkySNskZB5WvIAQxWhPDYQtsr4KkOnydApIVTJNtbWUQ3hi rGO1yNfFUbBRFwUnPlq+0v1ECaaTk3g= ARC-Authentication-Results: i=1; imf07.hostedemail.com; dkim=pass header.d=bytedance.com header.s=google header.b=TQeZsPYY; spf=pass (imf07.hostedemail.com: domain of lizhe.67@bytedance.com designates 209.85.214.176 as permitted sender) smtp.mailfrom=lizhe.67@bytedance.com; dmarc=pass (policy=quarantine) header.from=bytedance.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1729147410; a=rsa-sha256; cv=none; b=54tOy8P9lh9e90SQyKzDnS12nAO/XWa7GUS2jZc8rB3iMckZNtoIGT0dhii6SapXMRwebK qnHUufg/leDbgWG4Dxv4VUgdiQHGa2BFoptR6/8BIxLcr/HC+3O4NDMo4W9on2UmpEhGQi cA2dkdiQ3jTGgYM5PLOmGWjjDNe0F0s= Received: by mail-pl1-f176.google.com with SMTP id d9443c01a7336-20c693b68f5so6601735ad.1 for ; Wed, 16 Oct 2024 23:46:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bytedance.com; s=google; t=1729147600; x=1729752400; darn=kvack.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=tv5UJ/Xk45I32p3AVak0iA4xEipZAR9oPUhdZra2dK0=; b=TQeZsPYYoiAeb4YeFfV3ofvNQm83O/hQMC9434eVO4GPlvUo6jQlJhr3RSsztf6Yky D9jV1FouwYR0DwonsthZnUNkXZ8t+Cd4tirCNr8+htV3nGhmvcMmK7TzsiOZZf7uxrZz KZsSB4UrQnijb5aCbZnXRZNIFOgOTuk5Fp8AvEHaFBcuOJjOiyU6UNTbIxIxCBcgCLkJ wdv3HRWft+fzoKB4wFQNxKPGEYZzUFFUafbEmGY7nWuflB4psbEKD/+KhLUenSIcj6Kr hTD6ByKezxWpYE91oVZ4KjZ7/T60gwkwugj5tTBHEaNq7B0qbwTnlzKBrB2DdARKfsIP nAzw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1729147600; x=1729752400; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=tv5UJ/Xk45I32p3AVak0iA4xEipZAR9oPUhdZra2dK0=; b=cCYgQHbgDWHbVMpUjHm8rAbQgpRlTSB5ZNvSc0NmyTmodXEj5u3SqxwgTFC5DhtYct 7pY63TLGfl5t2e1MSwiTwmMpFIxFX1w1GvikbljXCJRPUbbkRQpaY5GUdG935p/jgwwP nRngujAw0v7J9AIBSPDz0gNfXEyfry/DhVuPt5kCxSzqD8WDxT5gOFtMuVsXMHnGA0CO AQc5KkUWanXYfJTIHehjwUsX+K8mmN38R26zl1z72OArwMvaxjfVPDPjJH5i+1ibebrx udHWRkDwPs3vFUrb3lVy569yvyoPTGWhR8FTtjN3OfFJYfwxIYL8uAuwnjDoydgBebGj TP+w== X-Forwarded-Encrypted: i=1; AJvYcCViNVhCKSx4BqW2XuOBHeiVUW9xWspR/GZo2HdHk0CvT4jm0/BroWX/Sf650OJQ0OjK3j7aD4e/Zw==@kvack.org X-Gm-Message-State: AOJu0Yy5tGMKxepT4lUbX6/W1U3hBCb21UgkfwwXPiE6V+VMKdYSv5yl ge/XLKU2qedOzEqG6EIIKCmNsM3BuuaK4dblV93Myxt3+ka33W7nRM/PrrWk1wo= X-Google-Smtp-Source: AGHT+IFAYfgIy3AbgiLfa0obsAVwN3fi3s02lU8uuKwdk6B7U1BGpCPxN9O4XcRG8RDsPtRfI6ReYA== X-Received: by 2002:a17:902:f545:b0:20c:ee48:94f3 with SMTP id d9443c01a7336-20cee489d9bmr163242905ad.14.1729147600311; Wed, 16 Oct 2024 23:46:40 -0700 (PDT) Received: from GQ6QX3JCW2.bytedance.net ([203.208.189.8]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-20d17f82c92sm38182635ad.45.2024.10.16.23.46.36 (version=TLS1_3 cipher=TLS_CHACHA20_POLY1305_SHA256 bits=256/256); Wed, 16 Oct 2024 23:46:39 -0700 (PDT) From: lizhe.67@bytedance.com To: llong@redhat.com Cc: akpm@linux-foundation.org, boqun.feng@gmail.com, linux-kernel@vger.kernel.org, linux-mm@kvack.org, lizhe.67@bytedance.com, mingo@redhat.com, peterz@infradead.org, will@kernel.org Subject: Re: [RFC 1/2] rwsem: introduce upgrade_read interface Date: Thu, 17 Oct 2024 14:46:32 +0800 Message-ID: <20241017064632.82771-1-lizhe.67@bytedance.com> X-Mailer: git-send-email 2.45.2 In-Reply-To: <7f7b277a-7019-4bf4-b100-0505c6ce9737@redhat.com> References: <7f7b277a-7019-4bf4-b100-0505c6ce9737@redhat.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: 700D84000C X-Stat-Signature: 5xkz8np63iwhrgc8q9qimw98nuyrmwy6 X-Rspam-User: X-HE-Tag: 1729147588-120659 X-HE-Meta: U2FsdGVkX1//a76OGYz/uCtTF5zl6VJooR6Ek1Z3cfKHnw68M+x4v+UvWeOL/R+Agab+Zh1XytQ4euTz+zrBBnTTy8Z8tqyi0uFfKfmVOZIlA0D5/IZvlED7UEZrEpWprHX2jJ8Z3ic/7JQTWmYVzT7+CPGqpQ4UkG4HS6FNSgqrFaLPeYHsr9CGIeBej+Hgbc0vCxrh0orNjembUiN1+NYlQ+oY4tzSNA9Szj/1hE5B0+xxL7i7CCjdM8M4xr71Z0FHMwqcPh3jfFrNwO1DGr3Ingb6MKvVlvZeoxNRpU+AXq9Jn79zX1h6IB9aVRl5QBYkwiVbMTIEoVyIqeEbiH/aCmcXhGtPszkvJ6rExwk/KfZyZrhTTSTkj++hmahdy+8dJP+s9g0MMWuPtte291ypcDzlO6KzWu8z943Wzo+sloVUer8l6RRs9QXBH1CeucmNrwaSgHoVDv/gdgtBui452qcpfwf/2Xj94axmdBo9ARjZhmMKm0fpjlpEWK2/N8Tv//f60SdQ7joJP4kvtO95w6TK/WcLpbhRPSTw95QCcfHK7drGJuRFmPEXevp8bPvtId4qBs8/cqeOu0IAgchBN2/7j47yTndwV9VITYky+ZKdnCEKEL5AR/dowWC/KxMiNerwt3Jke80RA5GlKdngG2SOdOW78riZwlOTpEHvyvv11s7TyUm/Odsh6FASQnPkv3AwyMySGA1ZiE+w+0axQ9Y6b8de0LMsApKEHEalYfxwImXUiVhEN9mcidnxjOXsh0KSqmMwC2BRsfstG42gy94VOJKPu4oesDf+5bjt6q+igzcgPnqil1+5dD9Q42v8rISG6GxFJQmr59B0M8Ux5vsMmQTunpsaV9SdOUA/f2z1UBIBmkpAsesOjrgba94SqwFNrxrGW8YtzSR/1rnDJSM1GwLQvT/oM56Vg9sdNsfrmiNJ+3KmqMA6KxZCAhVnCCRFcKpkd3qB0bg rwzhJs/U loEjEgVyMLfNlymagZeZ8+AfvZWgcuxB9xXftnvs1N8iYaq17Ou8jytDAc5Fzb0nPEAUR41pItjuud+YOQ0n2WZ6e9EuArCuM0qnUcL1MLP5VttL91+J+gJVm8zRb0aRDiTDUG+PeW2QCFARFTWp91RGI+Ea0bu8JcHRJpYVoijC2dzzNSgMOsBUVQTvYG1xKLMNsDl1goS3eqUK9dTSfFrpmRNDQq3w0yegQOr019Q2H+BLUoNF1d367v89PiciruyP02jYtjhJVeAdRiafqhY9v7+kmB8zBrctbqzk88GClwuy8WftfRF2gmsMJgXYpjAe4/ejXCIPxPrJqP5BHOr6OeIu9PrY+AUAm5buuGLjnksMVp00d4AA616XXkHwzWFSgL0QrQU+peKC4zd1BxZ4SHg86oNE9O3kFxAssPLDebm4= 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: List-Subscribe: List-Unsubscribe: On Wed, 16 Oct 2024 10:23:14 -0400, llong@redhat.com wrote: >> +static inline void rwsem_set_owner_upgrade(struct rw_semaphore *sem) >> +{ >> + lockdep_assert_preemption_disabled(); >> + atomic_long_set(&sem->owner, (long)current | RWSEM_UPGRADING | >> + RWSEM_READER_OWNED | RWSEM_NONSPINNABLE); >> +} > >Because of possible racing between 2 competing upgraders, read lock >owner setting has to be atomic to avoid one overwriting the others. I did concurrent processing at the very beginning of the function __upgrade_read(). Is it not necessary to do concurrent processing here? The relevant code is as follows. +static inline int __upgrade_read(struct rw_semaphore *sem) +{ + long tmp; + + preempt_disable(); + + tmp = atomic_long_read(&sem->count); + do { + if (tmp & (RWSEM_WRITER_MASK | RWSEM_FLAG_UPGRADE_READ)) { + preempt_enable(); + return -EBUSY; + } + } while (!atomic_long_try_cmpxchg(&sem->count, &tmp, + tmp + RWSEM_FLAG_UPGRADE_READ + RWSEM_WRITER_LOCKED - RWSEM_READER_BIAS)); >This new interface should have an API similar to a trylock. True if >successful, false otherwise. I like the read_try_upgrade() name. I can't agree more. I will add an read_try_upgrade() API in v2. >Another alternative that I have been thinking about is a down_read() >variant with intention to upgrade later. This will ensure that only one >active reader is allowed to upgrade later. With this, upgrade_read() >will always succeed, maybe with some sleeping, as long as the correct >down_read() is used. I haven't figured out how to do this yet. If the current upgrade_read idea is also OK, should I continue to complete this patchset according to this idea? >Cheers, >Longman Thanks for your review!