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 B0EFEECAAA1 for ; Tue, 6 Sep 2022 15:46:41 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 0F809802A2; Tue, 6 Sep 2022 11:46:41 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 07ECD80224; Tue, 6 Sep 2022 11:46:41 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E630C802A2; Tue, 6 Sep 2022 11:46:40 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id D550180224 for ; Tue, 6 Sep 2022 11:46:40 -0400 (EDT) Received: from smtpin10.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id A411F121917 for ; Tue, 6 Sep 2022 15:46:40 +0000 (UTC) X-FDA: 79882088160.10.7B89BEF Received: from mail-io1-f51.google.com (mail-io1-f51.google.com [209.85.166.51]) by imf03.hostedemail.com (Postfix) with ESMTP id 4D5B22006C for ; Tue, 6 Sep 2022 15:46:40 +0000 (UTC) Received: by mail-io1-f51.google.com with SMTP id n202so9231763iod.6 for ; Tue, 06 Sep 2022 08:46:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date; bh=01CsnEEQfLK1uOpVQ+HH6686vEI9WQZhnhn7tltGMc4=; b=o7ZUoR1kIbCZSNNyLbvrwwtPxnTYEllaZY9cFNDDCCA7TAcp0hkIs2NMKLazX0j/Wb AWxxBk+k5G23dVl64yevMX+VdSw/FzkljOCmS/xASd595atoUnaTjkJmrmR9WjiCsxKE VuyYGhKnfagDzQZ6sGO0kr/wninknslufsnoLThmyJZSuYTU38KSG2qsTZT0WtI8/TFp LX/qK2c50VdG2SVsnEj1+xTC+UMWubZMyMO7uNilERQu9uv4D2aQqwP7+M8bGR8KWyFm OnnkvtEInWpmkIYk4qBKTNg02wGwVlJLJMtpY5HIQ1/Z8WKMbLgAbK2PJvysrvsqnBR+ epoA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date; bh=01CsnEEQfLK1uOpVQ+HH6686vEI9WQZhnhn7tltGMc4=; b=6QEQdyf3aqZUrTgCxYUAoIvwuQXqUkMM+vPQm/CP8XHlFaeT0ppiyKu/bAlyDR9gvC nPQbuH+lfDABT1klTAG2uWbH8RKwJ76+4mTWE+3c3lHvRciy4R6tTd1qQc3HOJ89uipm RPDYtKpui34pIXVLFtYekKT9vmfn+Kmvj/e6dtTKYiD2PlGVCx6vY4YJuAmkYCOLv4by /5LGKr9NNY1e6FIFt/awUhU2ef0RGaduQPtkzhH0MiZCdvpOFugnXC5h6tQDURYRKI0E JPtZ3vRm/ekpAqoSZ9dY9BWAho+xR6D7DKdJya2FsnoeqKa9RLU2zIoEAKa4kJGIGsFE 6jRw== X-Gm-Message-State: ACgBeo0Ij7DH3G1xPidXvf/o/pmKwAvN8JMj8oUpWqi4zAHxNL+o/Rhf NN76suKxFuE6VxF2JTn045Z38+1J4gMTcRoe/Pq0bQ== X-Google-Smtp-Source: AA6agR4npg7xYhO3jV9bPgCe/qZLaBiwpkb5NlSVTaZJNdUAJnVvwtlRJpA1bjafBWAWUuAzLEiUFw/4MgDT30cQhzs= X-Received: by 2002:a05:6638:1492:b0:34c:d42:ac2f with SMTP id j18-20020a056638149200b0034c0d42ac2fmr16182031jak.305.1662479199238; Tue, 06 Sep 2022 08:46:39 -0700 (PDT) MIME-Version: 1.0 References: <20220901173516.702122-1-surenb@google.com> <20220905203503.tqtr36fsfg4guk4j@moria.home.lan> In-Reply-To: <20220905203503.tqtr36fsfg4guk4j@moria.home.lan> From: Suren Baghdasaryan Date: Tue, 6 Sep 2022 08:46:28 -0700 Message-ID: Subject: Re: [RFC PATCH RESEND 00/28] per-VMA locks proposal To: Kent Overstreet Cc: Michal Hocko , Andrew Morton , Michel Lespinasse , Jerome Glisse , Vlastimil Babka , Johannes Weiner , Mel Gorman , Davidlohr Bueso , Matthew Wilcox , "Liam R. Howlett" , Peter Zijlstra , Laurent Dufour , Laurent Dufour , "Paul E . McKenney" , Andy Lutomirski , Song Liu , Peter Xu , David Hildenbrand , dhowells@redhat.com, Hugh Dickins , Sebastian Andrzej Siewior , David Rientjes , Axel Rasmussen , Joel Fernandes , Minchan Kim , kernel-team , linux-mm , linux-arm-kernel@lists.infradead.org, linuxppc-dev@lists.ozlabs.org, x86@kernel.org, LKML Content-Type: text/plain; charset="UTF-8" ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1662479200; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=01CsnEEQfLK1uOpVQ+HH6686vEI9WQZhnhn7tltGMc4=; b=U2wboT7Lh8BBWND1aozv6SQ2qF454+QrtqrYIKyIidz9a0qdHx4TxqXGuR4TXjp2QWtWnl EZN71dsvhBNM005kPUEr+NDB8/BDdVqankd6Zqxc0fj3A/3OwW+ZdFaGuMlIs1IljAmx97 NSirHHUkMJVJtVJDOtolzDutmG4+gfI= ARC-Authentication-Results: i=1; imf03.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=o7ZUoR1k; spf=pass (imf03.hostedemail.com: domain of surenb@google.com designates 209.85.166.51 as permitted sender) smtp.mailfrom=surenb@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1662479200; a=rsa-sha256; cv=none; b=zKbx0MKn7Gi8ZizalQKCZsT/IaX7PGIMSnI7T0xyL0KmioWe/9Iht6kghilsC03tm8DmmM CNvT3DKBWqAOuZXYTG+dImo8ALaDLRlS01YW/AGxE7oaPVWtGuxvBNZDNLwf4iuM0pSL4n NIBbevxSAhcUHGYrhatTd/qp8RbCwgM= X-Rspamd-Queue-Id: 4D5B22006C Authentication-Results: imf03.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=o7ZUoR1k; spf=pass (imf03.hostedemail.com: domain of surenb@google.com designates 209.85.166.51 as permitted sender) smtp.mailfrom=surenb@google.com; dmarc=pass (policy=reject) header.from=google.com X-Rspamd-Server: rspam02 X-Rspam-User: X-Stat-Signature: 4iykufsyq3pb89h55h3a9z1sjtt4qky9 X-HE-Tag: 1662479200-307201 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 Mon, Sep 5, 2022 at 1:35 PM Kent Overstreet wrote: > > On Mon, Sep 05, 2022 at 11:32:48AM -0700, Suren Baghdasaryan wrote: > > On Mon, Sep 5, 2022 at 5:32 AM 'Michal Hocko' via kernel-team > > wrote: > > > > > > Unless I am missing something, this is not based on the Maple tree > > > rewrite, right? Does the change in the data structure makes any > > > difference to the approach? I remember discussions at LSFMM where it has > > > been pointed out that some issues with the vma tree are considerably > > > simpler to handle with the maple tree. > > > > Correct, this does not use the Maple tree yet but once Maple tree > > transition happens and it supports RCU-safe lookups, my code in > > find_vma_under_rcu() becomes really simple. > > > > > > > > On Thu 01-09-22 10:34:48, Suren Baghdasaryan wrote: > > > [...] > > > > One notable way the implementation deviates from the proposal is the way > > > > VMAs are marked as locked. Because during some of mm updates multiple > > > > VMAs need to be locked until the end of the update (e.g. vma_merge, > > > > split_vma, etc). > > > > > > I think it would be really helpful to spell out those issues in a greater > > > detail. Not everybody is aware of those vma related subtleties. > > > > Ack. I'll expand the description of the cases when multiple VMAs need > > to be locked in the same update. The main difficulties are: > > 1. Multiple VMAs might need to be locked within one > > mmap_write_lock/mmap_write_unlock session (will call it an update > > transaction). > > 2. Figuring out when it's safe to unlock a previously locked VMA is > > tricky because that might be happening in different functions and at > > different call levels. > > > > So, instead of the usual lock/unlock pattern, the proposed solution > > marks a VMA as locked and provides an efficient way to: > > 1. Identify locked VMAs. > > 2. Unlock all locked VMAs in bulk. > > > > We also postpone unlocking the locked VMAs until the end of the update > > transaction, when we do mmap_write_unlock. Potentially this keeps a > > VMA locked for longer than is absolutely necessary but it results in a > > big reduction of code complexity. > > Correct me if I'm wrong, but it looks like any time multiple VMAs need to be > locked we need mmap_lock anyways, which is what makes your approach so sweet. That is correct. Anytime we need to take VMA's write lock we have to be holding the write side of the mmap_lock as well. That's what allows me to skip locking in cases like checking if the VMA is already locked. > > If however we ever want to lock multiple VMAs without taking mmap_lock, then > deadlock avoidance algorithms aren't that bad - there's the ww_mutex approach, > which is simple and works well when there isn't much expected contention (the > advantage of the ww_mutex approach is that it doesn't have to track all held > locks). I've also written full cycle detection; that approcah gets you fewer > restarts, at the cost of needing a list of all currently held locks. Thanks for the tip! I'll take a closer look at ww_mutex. > > -- > To unsubscribe from this group and stop receiving emails from it, send an email to kernel-team+unsubscribe@android.com. >