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 10DDBC433F5 for ; Fri, 11 Feb 2022 18:26:44 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 7DD1C6B0078; Fri, 11 Feb 2022 13:26:43 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 78ABE6B007B; Fri, 11 Feb 2022 13:26:43 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 67AEB6B007D; Fri, 11 Feb 2022 13:26:43 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0002.hostedemail.com [216.40.44.2]) by kanga.kvack.org (Postfix) with ESMTP id 59B076B0078 for ; Fri, 11 Feb 2022 13:26:43 -0500 (EST) Received: from smtpin20.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id 08B48181AC9C6 for ; Fri, 11 Feb 2022 18:26:43 +0000 (UTC) X-FDA: 79131329886.20.9568EE4 Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.220.29]) by imf06.hostedemail.com (Postfix) with ESMTP id 5149B180003 for ; Fri, 11 Feb 2022 18:26:42 +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-out2.suse.de (Postfix) with ESMTPS id 292341F3A8; Fri, 11 Feb 2022 18:26:41 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_rsa; t=1644604001; 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=lagKek43O/qlYtO4egbfLmplkVBaMU559cGMwzFezxo=; b=K2BX9sNSDjEWvAhU0x5qHgKPtI+KVUPLVavnf8/L/YHsPtXCtzqGjOVvbTjjJKJ+GuEnfB 5+Gf651FgODORs5XHOhZarftbYzk0C8wdhBfe12w1McvstvCUMNOs6aC2ZgY/N7E3EVZX8 k4M44X3assACkkUXkQrBIyg9lPmi0IM= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_ed25519; t=1644604001; 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=lagKek43O/qlYtO4egbfLmplkVBaMU559cGMwzFezxo=; b=KTQc5p58rG+TvkAyrmsRVSVOg6xbHTtJXRQyYs1EK7uTfiYIrNczq97jvoYa4oiiFrPFnh d1aP+yYUh7Omf0AA== 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 D79F613CA5; Fri, 11 Feb 2022 18:26:40 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id WZsCNGCqBmJrIAAAMHmgww (envelope-from ); Fri, 11 Feb 2022 18:26:40 +0000 Message-ID: <64fd7f7d-f797-fa3a-303b-cf36c1a62820@suse.cz> Date: Fri, 11 Feb 2022 19:26:40 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.5.1 Subject: Re: [PATCH 10/13] mm/munlock: mlock_page() munlock_page() batch by pagevec Content-Language: en-US To: Hugh Dickins , Andrew Morton Cc: Michal Hocko , "Kirill A. Shutemov" , Matthew Wilcox , David Hildenbrand , Alistair Popple , Johannes Weiner , Rik van Riel , Suren Baghdasaryan , Yu Zhao , Greg Thelen , Shakeel Butt , linux-kernel@vger.kernel.org, linux-mm@kvack.org References: <8e4356d-9622-a7f0-b2c-f116b5f2efea@google.com> From: Vlastimil Babka In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Rspam-User: X-Rspamd-Server: rspam08 X-Rspamd-Queue-Id: 5149B180003 X-Stat-Signature: 999su8yqk83wj5admi9wa64a9wafefjj Authentication-Results: imf06.hostedemail.com; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b=K2BX9sNS; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b=KTQc5p58; spf=pass (imf06.hostedemail.com: domain of vbabka@suse.cz designates 195.135.220.29 as permitted sender) smtp.mailfrom=vbabka@suse.cz; dmarc=none X-HE-Tag: 1644604002-507530 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 2/6/22 22:47, Hugh Dickins wrote: > A weakness of the page->mlock_count approach is the need for lruvec lock > while holding page table lock. That is not an overhead we would allow on > normal pages, but I think acceptable just for pages in an mlocked area. > But let's try to amortize the extra cost by gathering on per-cpu pagevec > before acquiring the lruvec lock. > > I have an unverified conjecture that the mlock pagevec might work out > well for delaying the mlock processing of new file pages until they have > got off lru_cache_add()'s pagevec and on to LRU. > > The initialization of page->mlock_count is subject to races and awkward: > 0 or !!PageMlocked or 1? Was it wrong even in the implementation before > this commit, which just widens the window? I haven't gone back to think > it through. Maybe someone can point out a better way to initialize it. Not me, it seems. > Bringing lru_cache_add_inactive_or_unevictable()'s mlock initialization > into mm/mlock.c has helped: mlock_new_page(), using the mlock pagevec, > rather than lru_cache_add()'s pagevec. > > Experimented with various orderings: the right thing seems to be for > mlock_page() and mlock_new_page() to TestSetPageMlocked before adding to > pagevec, but munlock_page() to leave TestClearPageMlocked to the later > pagevec processing. > > Dropped the VM_BUG_ON_PAGE(PageTail)s this time around: they have made > their point, and the thp_nr_page()s already contain a VM_BUG_ON_PGFLAGS() > for that. > > This still leaves acquiring lruvec locks under page table lock each time > the pagevec fills (or a THP is added): which I suppose is rather silly, > since they sit on pagevec waiting to be processed long after page table > lock has been dropped; but I'm disinclined to uglify the calling sequence > until some load shows an actual problem with it (nothing wrong with > taking lruvec lock under page table lock, just "nicer" to do it less). > > Signed-off-by: Hugh Dickins Acked-by: Vlastimil Babka