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 08580ECAAD3 for ; Mon, 5 Sep 2022 18:33:01 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 644A1801FA; Mon, 5 Sep 2022 14:33:01 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 5CCB1801E6; Mon, 5 Sep 2022 14:33:01 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 44725801FA; Mon, 5 Sep 2022 14:33:01 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 2F396801E6 for ; Mon, 5 Sep 2022 14:33:01 -0400 (EDT) Received: from smtpin30.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id E6B0EC0468 for ; Mon, 5 Sep 2022 18:33:00 +0000 (UTC) X-FDA: 79878878520.30.FB4EE7E Received: from mail-io1-f50.google.com (mail-io1-f50.google.com [209.85.166.50]) by imf19.hostedemail.com (Postfix) with ESMTP id 85D2A1A0055 for ; Mon, 5 Sep 2022 18:33:00 +0000 (UTC) Received: by mail-io1-f50.google.com with SMTP id e195so7343249iof.1 for ; Mon, 05 Sep 2022 11:33:00 -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=FNv/KEMtf5XOtkND3AyjhcP/3pLjOBMwZm4O4kjr360=; b=i5KCDSUH/dFt94fpjc7Fphku0Tn3reBabaBpFtdU+oRbFh+e8Cx/DMlqQivEg1MZjm 7FbOvlY6Y9f+9LZ9N+zgTB71z3cagQ2sGfp1oudx0Kv1xpUW6Up8K51vig+01CsmnL3L C3xCWMqLQrpYBGvHC0UNi+yNQ6XvxIjh2dsHMNd34BBtJz1xyaPEvWMxsK55kusb2lJe FYhU7ADU9KYt1l8KwJpBXu48E1hUBJcr2CIqnesgVXkiai+CuNr/V0a+QqiqySxoUimH yIvsq78rMCW0kTv83Fiph1I394+CJ8Hgoqi6ZFAZmMb3pGsqLwLA4vfAoG5DeUW7LJqa cUpw== 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=FNv/KEMtf5XOtkND3AyjhcP/3pLjOBMwZm4O4kjr360=; b=ZivqKuSveD8Bq8g2qhNTVp+hYyoPVEY5N9KtQ3HoY4j81ykUpBCe7HhOY+iS3pgK9S fGY2K7ENwK3rdsAHI/pH0+LQk9VixeKA+0/3XhkQmoQ20XclinqjCtf2q4dBPpAe1rOd 4XdwN01T/Y5r2gqiwl1He1i5Zqme1Hr/RCAguaULcAntfqZlNWhyjhiI/qdCU6krttTS X9qpIc8covwoI6l9fS/RvNXnjV/ifP8eukRcuDfGquajOzws/D5SAhiiIBrET31P2BBA XQxrWUYz7kioQGbJ65CyceBlV9Mtj1889yiYjTFw3jIb2cFsQp9ve1n06N/7oVwOKefw 0N8g== X-Gm-Message-State: ACgBeo0BGXd/MYLCS+omIFJqCQfIjPlaXmCgo7ibGD0C130h/V6O6lJ9 tMBEFw/qaN6vuBTEdVSXhwCJ/j+dcNKQU3BtzDeeHg== X-Google-Smtp-Source: AA6agR7tgjJDEPLfwwS1LRrijFcmlJFxoiqhAebJjxrWU7CYsmX7SoR6nKTNAJ7nNJVYWRRFlsmMoE7vtwAV8983goQ= X-Received: by 2002:a02:740b:0:b0:349:bcdd:ca20 with SMTP id o11-20020a02740b000000b00349bcddca20mr28183219jac.110.1662402779688; Mon, 05 Sep 2022 11:32:59 -0700 (PDT) MIME-Version: 1.0 References: <20220901173516.702122-1-surenb@google.com> In-Reply-To: From: Suren Baghdasaryan Date: Mon, 5 Sep 2022 11:32:48 -0700 Message-ID: Subject: Re: [RFC PATCH RESEND 00/28] per-VMA locks proposal To: Michal Hocko Cc: 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 , Kent Overstreet , 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-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1662402780; a=rsa-sha256; cv=none; b=4oLYJLFOg0SXLF7fqqdGaJMvM5zyVfsuLOqgSWYpqHhed0UDK77iVipMI23QNmHiCDDvK+ 762I6/P35RcwJ2kZHKh1EFksFIMMy0FpxzuDQQeOZbgXczimWjSs1CG7J8vXjBu1O8IAWK NoV6HX24X/VmJ+l+iL7iE2JyY0zpD/M= ARC-Authentication-Results: i=1; imf19.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=i5KCDSUH; spf=pass (imf19.hostedemail.com: domain of surenb@google.com designates 209.85.166.50 as permitted sender) smtp.mailfrom=surenb@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1662402780; 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=FNv/KEMtf5XOtkND3AyjhcP/3pLjOBMwZm4O4kjr360=; b=lWP/flZSrXxSEnVzTBcg6GcM/206Sr9VyUPRH+2NeK2LXzESCl3vf0awoOrVTMCIGEMxTG dW4NFpzxd+i2k0jD8qEKGlXXXuLdRjb0Fs2hSkrw20JbBkKh4y485/bsRTO5OkzgSxvydz OA0956N1Xm951n+UZMOgGMUP7MkTmOo= X-Stat-Signature: xyrg7xjbd4yf3ejm4tbjgu17iuhrdf9f X-Rspamd-Queue-Id: 85D2A1A0055 Authentication-Results: imf19.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=i5KCDSUH; spf=pass (imf19.hostedemail.com: domain of surenb@google.com designates 209.85.166.50 as permitted sender) smtp.mailfrom=surenb@google.com; dmarc=pass (policy=reject) header.from=google.com X-Rspam-User: X-Rspamd-Server: rspam03 X-HE-Tag: 1662402780-408435 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 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. > > Thanks for working on this Suren! Thanks for reviewing! Suren. > -- > Michal Hocko > SUSE Labs > > -- > To unsubscribe from this group and stop receiving emails from it, send an email to kernel-team+unsubscribe@android.com. >