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 33D13C6FA83 for ; Sun, 11 Sep 2022 09:35:41 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 59FD980009; Sun, 11 Sep 2022 05:35:41 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 5283180008; Sun, 11 Sep 2022 05:35:41 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 3A1E980009; Sun, 11 Sep 2022 05:35:41 -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 24C0980008 for ; Sun, 11 Sep 2022 05:35:41 -0400 (EDT) Received: from smtpin10.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id C872B805E7 for ; Sun, 11 Sep 2022 09:35:40 +0000 (UTC) X-FDA: 79899297240.10.6151059 Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.220.28]) by imf20.hostedemail.com (Postfix) with ESMTP id 544571C00A9 for ; Sun, 11 Sep 2022 09:35:40 +0000 (UTC) Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by smtp-out1.suse.de (Postfix) with ESMTPS id A7F7521E99; Sun, 11 Sep 2022 09:35:38 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_rsa; t=1662888938; h=from:from:reply-to: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; bh=9Lc3vR3minJtB/44lBRTyQejWooVRYylPWrQ2JvEp1c=; b=MaJLVWPQsh71YKDB3HnJgYZcoRFq3u90TGLqyadSycRXOfbpdLNOhF7jYJ7wCymnlaOQfy tQ9Y98dwJx0BjGNKItq1K2MZZWqZ7VjFqT/UMwLPtJBlcJA4fTEPB3DeUWXQySouftTEmC Ky8YnNCvqPf8JLLUmYNl5CYA/YY/50M= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_ed25519; t=1662888938; h=from:from:reply-to: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; bh=9Lc3vR3minJtB/44lBRTyQejWooVRYylPWrQ2JvEp1c=; b=8akfSuHi78TNqxzhhYCqjW2GfEzFez7f2C0WbZ30IncNuZEB6firo2r44VOcgN+jYzwA67 5vTZ6qN3UH8IbODA== Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by imap2.suse-dmz.suse.de (Postfix) with ESMTPS id 41DC6133E6; Sun, 11 Sep 2022 09:35:38 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id Jd4fD+qrHWN3VwAAMHmgww (envelope-from ); Sun, 11 Sep 2022 09:35:38 +0000 Message-ID: Date: Sun, 11 Sep 2022 11:35:37 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.2.1 Subject: Re: [RFC PATCH RESEND 00/28] per-VMA locks proposal Content-Language: en-US To: Suren Baghdasaryan , Kent Overstreet Cc: Andrew Morton , Michel Lespinasse , Jerome Glisse , Michal Hocko , 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 , bigeasy@linutronix.de, 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 References: <20220901173516.702122-1-surenb@google.com> <20220901205819.emxnnschszqv4ahy@moria.home.lan> From: Vlastimil Babka In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1662888940; a=rsa-sha256; cv=none; b=EC7RlcYZZUKYFZwn3ZS55hD00ps28LVNRSXAFHP7IFz48dVpVWhlQudTePU3g60yj9psp2 e68vpKbk2kqP0fTpyZeNv9OVXWOErJ1Er0XfjfAvJQPXJaQadbJcuNBd1G56sMMDzjosr/ Wq6laS1KKowfhY3a+/7bB05yV6X+RH0= ARC-Authentication-Results: i=1; imf20.hostedemail.com; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b=MaJLVWPQ; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b=8akfSuHi; spf=pass (imf20.hostedemail.com: domain of vbabka@suse.cz designates 195.135.220.28 as permitted sender) smtp.mailfrom=vbabka@suse.cz; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1662888940; 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=9Lc3vR3minJtB/44lBRTyQejWooVRYylPWrQ2JvEp1c=; b=uNW8QTNwTs2yPhRCeP82xndDZ8VLAfMZpT8uYcGQT9j1cCLypChq+WPWhY7/riWn0J50C7 M1QtJcaHB9VGf8pNDBmcVm7YKwzlsKGZ2C05uTwJwHLCRv7qAb7Nbpr6kNKVc1N+YjCkuO GeoSBHIzIr6Svd8s185ZVkeSgmvMsUQ= Authentication-Results: imf20.hostedemail.com; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b=MaJLVWPQ; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b=8akfSuHi; spf=pass (imf20.hostedemail.com: domain of vbabka@suse.cz designates 195.135.220.28 as permitted sender) smtp.mailfrom=vbabka@suse.cz; dmarc=none X-Rspam-User: X-Stat-Signature: 6wkty56ezbxycfdhiuqkorxz454a9z8s X-Rspamd-Queue-Id: 544571C00A9 X-Rspamd-Server: rspam01 X-HE-Tag: 1662888940-553750 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 9/2/22 01:26, Suren Baghdasaryan wrote: > On Thu, Sep 1, 2022 at 1:58 PM Kent Overstreet > wrote: >> >> On Thu, Sep 01, 2022 at 10:34:48AM -0700, Suren Baghdasaryan wrote: >> > Resending to fix the issue with the In-Reply-To tag in the original >> > submission at [4]. >> > >> > This is a proof of concept for per-vma locks idea that was discussed >> > during SPF [1] discussion at LSF/MM this year [2], which concluded with >> > suggestion that “a reader/writer semaphore could be put into the VMA >> > itself; that would have the effect of using the VMA as a sort of range >> > lock. There would still be contention at the VMA level, but it would be an >> > improvement.” This patchset implements this suggested approach. >> > >> > When handling page faults we lookup the VMA that contains the faulting >> > page under RCU protection and try to acquire its lock. If that fails we >> > fall back to using mmap_lock, similar to how SPF handled this situation. >> > >> > 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). Tracking all the locked VMAs, avoiding recursive locks >> > and other complications would make the code more complex. Therefore we >> > provide a way to "mark" VMAs as locked and then unmark all locked VMAs >> > all at once. This is done using two sequence numbers - one in the >> > vm_area_struct and one in the mm_struct. VMA is considered locked when >> > these sequence numbers are equal. To mark a VMA as locked we set the >> > sequence number in vm_area_struct to be equal to the sequence number >> > in mm_struct. To unlock all VMAs we increment mm_struct's seq number. >> > This allows for an efficient way to track locked VMAs and to drop the >> > locks on all VMAs at the end of the update. >> >> I like it - the sequence numbers are a stroke of genuius. For what it's doing >> the patchset seems almost small. > > Thanks for reviewing it! > >> >> Two complaints so far: >> - I don't like the vma_mark_locked() name. To me it says that the caller >> already took or is taking the lock and this function is just marking that >> we're holding the lock, but it's really taking a different type of lock. But >> this function can block, it really is taking a lock, so it should say that. >> >> This is AFAIK a new concept, not sure I'm going to have anything good either, >> but perhaps vma_lock_multiple()? > > I'm open to name suggestions but vma_lock_multiple() is a bit > confusing to me. Will wait for more suggestions. Well, it does act like a vma_write_lock(), no? So why not that name. The checking function for it is even called vma_assert_write_locked(). We just don't provide a single vma_write_unlock(), but a vma_mark_unlocked_all(), that could be instead named e.g. vma_write_unlock_all(). But it's called on a mm, so maybe e.g. mm_vma_write_unlock_all()?