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 44C45E77180 for ; Wed, 11 Dec 2024 15:20:19 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 753446B0089; Wed, 11 Dec 2024 10:20:18 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 702176B008C; Wed, 11 Dec 2024 10:20:18 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 5CACD6B0095; Wed, 11 Dec 2024 10:20:18 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 414396B0089 for ; Wed, 11 Dec 2024 10:20:18 -0500 (EST) Received: from smtpin29.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id C298DA1243 for ; Wed, 11 Dec 2024 15:20:17 +0000 (UTC) X-FDA: 82883039064.29.317DBEF Received: from mail-qt1-f174.google.com (mail-qt1-f174.google.com [209.85.160.174]) by imf22.hostedemail.com (Postfix) with ESMTP id 52AF4C0013 for ; Wed, 11 Dec 2024 15:19:51 +0000 (UTC) Authentication-Results: imf22.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=LMppScEt; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf22.hostedemail.com: domain of surenb@google.com designates 209.85.160.174 as permitted sender) smtp.mailfrom=surenb@google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1733930405; 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-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=brFp1j3FNkXikD4kXv2EisLQFnKxPJZnLCQQZU1UlHQ=; b=4n8biBwEKUWjtFs+JzpO5wj/wz5TkkkEPwGoflHQsGl2CcconDdGLjq29On3c8hz9J9maM iaXmfrHMWqEnZMLFHI+HVN4sdsRdWou/8Ddp1ivvMAAmucpGyeEp2uWB2b+YluaT2xG84p W4UEWsPwmjuyNCYsMYCw6LEjQGJboAE= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1733930405; a=rsa-sha256; cv=none; b=1LgSs+TW67aHUpZp2TjeOPEIOleZTDuEfnwU6CyPv3weO0GH1HaZRz1TbCfnPLJWTPebtW TpCfQyAjCXlbbGjqPq9ePTL7HmRB8sh9g5DpFXb+wDI61OFLvm14/YlkiaGmXaFAzUtmJA xi3TnURpBV7nSeeAj+gK5ULPao843NA= ARC-Authentication-Results: i=1; imf22.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=LMppScEt; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf22.hostedemail.com: domain of surenb@google.com designates 209.85.160.174 as permitted sender) smtp.mailfrom=surenb@google.com Received: by mail-qt1-f174.google.com with SMTP id d75a77b69052e-4674c22c4afso247391cf.1 for ; Wed, 11 Dec 2024 07:20:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1733930415; x=1734535215; darn=kvack.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=brFp1j3FNkXikD4kXv2EisLQFnKxPJZnLCQQZU1UlHQ=; b=LMppScEtXBUz+jrZe4+MRokQFqFjVTKD3Sw/QqRUNIzi1kIQ97ph6CbbfH4ZmnT2s6 ndgxmssQpqNy8NFH7egT9JUxUm6cRvu80Tuhbo58jv1tIM/tWP3Iru4n9hZT4OYfr91r /0JCiiG4nnI/O/ou8xq15Q+wFMH3XTOm5UYqIszBBWGE3kzR+xT7bbSBFuvOh6RfUlTT L6gjhosdhvFkfauVuK1pVJb/kCgFKqK4puHMI0/QHVR21pXF4YyTTi89Hp3IYGqAW+qC AP1kEJYFENF7w7gimkVtZFmKPJhMJOxgviaLqeTs1B3Ebut5U5aAf90MzjmQonQ5z6bM yKPA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1733930415; x=1734535215; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=brFp1j3FNkXikD4kXv2EisLQFnKxPJZnLCQQZU1UlHQ=; b=DBjWrif1XMIlTp3wP3e7fJnp9Xv0i3+JvnpGLVoG3n2Xdv0mC9N7KTl5OviilBUiXX 6CfpGnJwuaHd2W1By6oZt+NG1SBJ6IP0+T6wLbdsjXfoE/kFcLaMhWSaFHkr0batewyM 3fWgX+CKu+idHPFlEVzts+M+80efrpQDyQrjUtR+oao+f2To8ju+CwwM46kcd6+ArZ1J LrMSs7q84Le2vnf/6Q55WxBdbW4n1b/HRnifx0bo4xViasCd6Q98Y5gm/xptQZWH1L8Z MH0EtywQ1oSSgfmGuqnGOI8WJLyrHSwPAwIHJ3WDYxZOIUS7H0N85/niu1QT0KsOvSGM Dq6g== X-Forwarded-Encrypted: i=1; AJvYcCXUiCRgV5iKe7DutP5DjtCpCgFf2YjK7L1I6dOTJQFboBIMimeiWrXdx5StVR0YpeXpQUxXSpE1GA==@kvack.org X-Gm-Message-State: AOJu0Ywgx1mt7PMXMiolleoEoX7GaH/T6P1pHfiz0AIjYnqabYtZ+5sl 5eUT6XzFZQaHi5W4Lrr5OeNlvCMP72u0DIojVXnaBv5eQCy0i2+NIFDcvUAin3Vo9MTFEpkEkwo zAKOcmVI0k7kYZnQ4hWSFypjgLsogV8hemF38 X-Gm-Gg: ASbGncuB0hLGa/351ua/+R6NEOI3v+W31QQKGQAx+nLbrvkoCu788l6hJ7I7+rie/S4 F1k4WhY9emUt2qJZeanl5Eopu9r/v4eecs5tWuy0X1q9ub40/Idp6ctJHwy8N2Ls9zg== X-Google-Smtp-Source: AGHT+IHu2VbMB49y+iTCluJ2NomAiKyndnfffuEwxHdnIL3N6UHlxRCiW6C/XC3v82eUhvtJIDU+dvXD+IWEY4VEzKg= X-Received: by 2002:a05:622a:5a99:b0:466:9003:aae6 with SMTP id d75a77b69052e-46788c83ae6mr5044671cf.2.1733930414668; Wed, 11 Dec 2024 07:20:14 -0800 (PST) MIME-Version: 1.0 References: <20241111205506.3404479-1-surenb@google.com> <20241111205506.3404479-4-surenb@google.com> <20241210223850.GA2484@noisy.programming.kicks-ass.net> <20241211082541.GQ21636@noisy.programming.kicks-ass.net> In-Reply-To: <20241211082541.GQ21636@noisy.programming.kicks-ass.net> From: Suren Baghdasaryan Date: Wed, 11 Dec 2024 07:20:03 -0800 Message-ID: Subject: Re: [PATCH 3/4] mm: replace rw_semaphore with atomic_t in vma_lock To: Peter Zijlstra Cc: Matthew Wilcox , akpm@linux-foundation.org, liam.howlett@oracle.com, lorenzo.stoakes@oracle.com, mhocko@suse.com, vbabka@suse.cz, hannes@cmpxchg.org, mjguzik@gmail.com, oliver.sang@intel.com, mgorman@techsingularity.net, david@redhat.com, peterx@redhat.com, oleg@redhat.com, dave@stgolabs.net, paulmck@kernel.org, brauner@kernel.org, dhowells@redhat.com, hdanton@sina.com, hughd@google.com, minchan@google.com, jannh@google.com, shakeel.butt@linux.dev, souravpanda@google.com, pasha.tatashin@soleen.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org, kernel-team@android.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Stat-Signature: rcaie83nsz47885dfwoffkym3kp6n4bj X-Rspamd-Queue-Id: 52AF4C0013 X-Rspam-User: X-Rspamd-Server: rspam01 X-HE-Tag: 1733930391-634113 X-HE-Meta: U2FsdGVkX189t2a9Y0FPClWCHQtXHGz9CiOzqj6bAHJRiJF1EJb1SmsBUCOYOKIPhA8s4OnLBjLp5YoQi+DFDHBu4UQLQAKPC4rDEXFG2y78xul5NyZ43zVoHwQnaqkU/DeR4+SQ824bZ79ZQf8HZlkK81owA41UsJDHLK/XurAibNPLueZDRvD5zb6rSo2bhFcMAwug5jpu5QYcAsymXD7+0Phpw+xKFszAG82rvMxQWdFUKxfIFU/VMBXulbfdhx0YVuCvbbw6uNuB2eYH206C4tXqDL7mFJeQM79Yz6MiBf673l+jmbzihRKQbTCiOmdI8JCLfB70BE+mYCyqg9AXgIzLXRyLpjf7JJ9iEvWWMoP/OeleeEMSJiYr31JQ+DKbBY2ySNQhGSfLxAPN2RzJcpPAhW5b9YKk18ANm5WJ+jZ9U2MMO4OS1tp0j5tkY7QT9N0a4WJX3iLR1+AiZZCB5aIUbca4AqWkbgtnGaHU80L3PM+cY3c1WUmtSMhNWxYIYGZwj+HDO4VTrgqGef/5qF8+BCiWwaCPfwXjEbBy0xk3M8d2WGuyK7Xh1/G/y8UI+RAWT05yOWC9TmxJMEsnbdQdkeJjucboOHscqp0cDrUD4H9Nw38bbW6oKI5g+u6jkopjWgPREoCq2y3/HYH5CKKA99lq6NtaBRjVKKsgu39QWxUVj/fTQngXbPM37YnHb/zpD7T/s1suK4nYLSr6DwgEqVLOkWw3pz2+nyrsyKHOkIen27HkqQhNuzAI7738wyZ4t4ou8m45HxZCg4DF/CKrJySw8brkjwJ1/a77cC/PtH6PPMb3bTlHnthcrMCEN3LeUJwsOs0SCPznqcFRUOvIP0mJ8MdZvUe8FatDJVdzuwtsB+uXHqerAMD7v9Zjm7PPmuOmeYwevtUkrNIOXPDn8px0X+w2+MEWwyEmJ9n7sFunyDYQkPX7WvDaB+zXXwuG60QTdk8z9vJ IEThl1ZV iIeJLvvFY9P4gKBZ/SPk16rypEcP1bp/H2xj5rB/SGpFaFXuWFYBcCUJpbG6QRtQw4Hdvh83il8Z7qEDMxAp5D453Ak6n5njO/6lrBW6JWteFyuJdVgdhooWerTRN/yUzrjkh1ZWA12XxW411uYM0CsWh1GUPzd5843hR54d+m49gHXfv6E3RvhrMzldhmabqdMnJx2/bLQN+rfcu9wOJ8LSsXJp/2uYGqj3fv2Q+PQfMtjvvEIkGAz5eRQ1jpudn0H2efIY4Noj2RfiYKypUlzSE3zvMshUAqgwGRGs9dUNhqiY= X-Bogosity: Ham, tests=bogofilter, spamicity=0.013796, 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, Dec 11, 2024 at 12:25=E2=80=AFAM Peter Zijlstra wrote: > > On Tue, Dec 10, 2024 at 03:37:50PM -0800, Suren Baghdasaryan wrote: > > > > Replace vm_lock with vm_refcnt. Replace vm_detached with vm_refcnt = =3D=3D 0 > > > -- that is, attach sets refcount to 1 to indicate it is part of the m= as, > > > detached is the final 'put'. > > > > I need to double-check if we ever write-lock a detached vma. I don't > > think we do but better be safe. If we do then that wait-until() should > > accept 0x8000'0001 as well. > > vma_start_write() > __is_vma_write_locked() > mmap_assert_write_locked(vma->vm_mm); > > So this really should hold afaict. > > > > RCU lookup does the inc_not_zero thing, when increment succeeds, comp= are > > > mm/addr to validate. > > > > > > vma_start_write() already relies on mmap_lock being held for writing, > > > and thus does not have to worry about writer-vs-writer contention, th= at > > > is fully resolved by mmap_sem. This means we only need to wait for > > > readers to drop out. > > > > > > vma_start_write() > > > add(0x8000'0001); // could fetch_add and double check the hig= h > > > // bit wasn't already set. > > > wait-until(refcnt =3D=3D 0x8000'0002); // mas + writer ref > > > WRITE_ONCE(vma->vm_lock_seq, mm_lock_seq); > > > sub(0x8000'0000); > > > > > > vma_end_write() > > > put(); > > > > We don't really have vma_end_write(). Instead it's vma_end_write_all() > > which increments mm_lock_seq unlocking all write-locked VMAs. > > Therefore in vma_start_write() I think we can sub(0x8000'0001) at the > > end. > > Right, I know you don't, but you should :-), I've suggested adding this > before. I'll look into adding it. IIRC there was some issue with that but I can't recall... > > > > vma_start_read() then becomes something like: > > > > > > if (vm_lock_seq =3D=3D mm_lock_seq) > > > return false; > > > > > > cnt =3D fetch_inc(1); > > > if (cnt & msb || vm_lock_seq =3D=3D mm_lock_seq) { > > > put(); > > > return false; > > > } > > > > > > return true; > > > > > > vma_end_read() then becomes: > > > put(); > > > > > > > > > and the down_read() from uffffffd requires mmap_read_lock() and thus > > > does not have to worry about writers, it can simpy be inc() and put()= , > > > no? > > > > I think your proposal should work. Let me try to code it and see if > > something breaks. > > Btw, for the wait-until() and put() you can use rcuwait; that is the > simplest wait form we have. It's suitable because we only ever have the > one waiter. Yes, Davidlohr mentioned that before. I'll do that. Thanks!