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 10112ECAAD5 for ; Mon, 5 Sep 2022 20:35:14 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 8B80980202; Mon, 5 Sep 2022 16:35:13 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 8672A801E6; Mon, 5 Sep 2022 16:35:13 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 72EF680202; Mon, 5 Sep 2022 16:35:13 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 6467C801E6 for ; Mon, 5 Sep 2022 16:35:13 -0400 (EDT) Received: from smtpin26.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 2E557AB7EB for ; Mon, 5 Sep 2022 20:35:13 +0000 (UTC) X-FDA: 79879186506.26.A64B9EE Received: from out0.migadu.com (out0.migadu.com [94.23.1.103]) by imf04.hostedemail.com (Postfix) with ESMTP id 642F54006A for ; Mon, 5 Sep 2022 20:35:12 +0000 (UTC) Date: Mon, 5 Sep 2022 16:35:03 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1662410110; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=OpP1uXm6ca6XBc1ONEJL5gkifMHj5fs70rHCFRmvOy8=; b=UY/kLXhSCop8V5EbyM6Vo2PNPn4IQk8/GFRnAap21SYUxPj2i6gjs8KI50f80Fsp8Xa6FE uuVJigYWXX7+vuoCs4T9565L2O1YZd4x8iWg9nweGuKJUkJg7Zaus5YpeaFA7mCLzRdbg2 1pMuKrhGTAly+U+OkQj6pwMjKTI/v3w= X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Kent Overstreet To: Suren Baghdasaryan 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 Subject: Re: [RFC PATCH RESEND 00/28] per-VMA locks proposal Message-ID: <20220905203503.tqtr36fsfg4guk4j@moria.home.lan> References: <20220901173516.702122-1-surenb@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Migadu-Flow: FLOW_OUT X-Migadu-Auth-User: linux.dev ARC-Authentication-Results: i=1; imf04.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b="UY/kLXhS"; spf=pass (imf04.hostedemail.com: domain of kent.overstreet@linux.dev designates 94.23.1.103 as permitted sender) smtp.mailfrom=kent.overstreet@linux.dev; dmarc=pass (policy=none) header.from=linux.dev ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1662410112; a=rsa-sha256; cv=none; b=WqNzWBlv2gNQhe4s5ip5bacAqwrJpXLjPFCn8TGE/oqzkQAp+ZNbndBAbyHFCpmer4+cGi jFdIEjJn1Z5nUnPZorJzkr0yrldjr8KrMtFUosi5wQe6f1Tm3ba/D6CAkM2okchCSPJ1OR dt8XyE7CK/X/xoZC0zJQb6E/nk9ymmY= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1662410112; 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=OpP1uXm6ca6XBc1ONEJL5gkifMHj5fs70rHCFRmvOy8=; b=TKDDVEQt3s/OF+M7TylG/z68XdIriY6JL+bOnZJpmVShRT0KyPsWPFjSX5B4OWzhmZ1ILi B+Bhusp6evFB/kRs+UX8+SIZkgyyriSKhIExufea470RKjPfI4O7p7txKnYQVgZjeqAVOp vk5V0v2oRbtF2C00yVbBZYcW8M93tSw= Authentication-Results: imf04.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b="UY/kLXhS"; spf=pass (imf04.hostedemail.com: domain of kent.overstreet@linux.dev designates 94.23.1.103 as permitted sender) smtp.mailfrom=kent.overstreet@linux.dev; dmarc=pass (policy=none) header.from=linux.dev X-Stat-Signature: 1w4japb4h7psr9kn54qaykufpxd9ocjs X-Rspam-User: X-Rspamd-Server: rspam11 X-Rspamd-Queue-Id: 642F54006A X-HE-Tag: 1662410112-201702 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 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. 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.