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 673D3C433F5 for ; Wed, 9 Mar 2022 17:53:29 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id E781B8D0002; Wed, 9 Mar 2022 12:53:28 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id E270E8D0001; Wed, 9 Mar 2022 12:53:28 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id CFAD08D0002; Wed, 9 Mar 2022 12:53:28 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0138.hostedemail.com [216.40.44.138]) by kanga.kvack.org (Postfix) with ESMTP id C08858D0001 for ; Wed, 9 Mar 2022 12:53:28 -0500 (EST) Received: from smtpin21.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 11909A0F87 for ; Wed, 9 Mar 2022 17:53:28 +0000 (UTC) X-FDA: 79225594896.21.AC9A5F9 Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.220.29]) by imf04.hostedemail.com (Postfix) with ESMTP id 4DC3640010 for ; Wed, 9 Mar 2022 17:53:27 +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 2E5281F381; Wed, 9 Mar 2022 17:53:24 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_rsa; t=1646848404; 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=QQbgQmZ6PRHPb/9wR++IbmiOxljvQwct8K2X9mbk5jg=; b=C1eeXWQPn86L5oKEGsqyB8X+5jm+AkbFjj8A/jy5ohgpA0rRXoxyucl+j0uDj8YluASb0c J6cXWftiuLwrDJpCjPdZkkTfDA4MgjFo6tLBm4UIi4jqdv35QMqezz5L7nuTZzNpl6Ky8c jUNKIalEebze1bILSnzjdXTJlF8ZPYA= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_ed25519; t=1646848404; 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=QQbgQmZ6PRHPb/9wR++IbmiOxljvQwct8K2X9mbk5jg=; b=prd1Aae/Nv629+iQjFG0ODrORuaA/bsFppCrzs1vV+lk+cZOmlEg7PO7dWejlbAoBi8Znl 3YoQ1CLVdY8EokCQ== 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 B125C13D7A; Wed, 9 Mar 2022 17:53:23 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id DpcIKpPpKGJdIwAAMHmgww (envelope-from ); Wed, 09 Mar 2022 17:53:23 +0000 Message-ID: Date: Wed, 9 Mar 2022 18:53:23 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.6.2 Subject: Re: [PATCH v3 2/9] mm: optimize do_wp_page() for fresh pages in local LRU pagevecs Content-Language: en-US To: David Hildenbrand , linux-kernel@vger.kernel.org Cc: Andrew Morton , Hugh Dickins , Linus Torvalds , David Rientjes , Shakeel Butt , John Hubbard , Jason Gunthorpe , Mike Kravetz , Mike Rapoport , Yang Shi , "Kirill A . Shutemov" , Matthew Wilcox , Jann Horn , Michal Hocko , Nadav Amit , Rik van Riel , Roman Gushchin , Andrea Arcangeli , Peter Xu , Donald Dutile , Christoph Hellwig , Oleg Nesterov , Jan Kara , Liang Zhang , linux-mm@kvack.org References: <20220131162940.210846-1-david@redhat.com> <20220131162940.210846-3-david@redhat.com> From: Vlastimil Babka In-Reply-To: <20220131162940.210846-3-david@redhat.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Rspam-User: X-Rspamd-Server: rspam12 X-Rspamd-Queue-Id: 4DC3640010 X-Stat-Signature: mca6mpa4oop8hnojo57j75nafqauttio Authentication-Results: imf04.hostedemail.com; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b=C1eeXWQP; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b="prd1Aae/"; spf=pass (imf04.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: 1646848407-238040 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 1/31/22 17:29, David Hildenbrand wrote: > For example, if a page just got swapped in via a read fault, the LRU > pagevecs might still hold a reference to the page. If we trigger a > write fault on such a page, the additional reference from the LRU > pagevecs will prohibit reusing the page. > > Let's conditionally drain the local LRU pagevecs when we stumble over a > !PageLRU() page. We cannot easily drain remote LRU pagevecs and it might > not be desirable performance-wise. Consequently, this will only avoid > copying in some cases. > > Add a simple "page_count(page) > 3" check first but keep the > "page_count(page) > 1 + PageSwapCache(page)" check in place, as > we want to minimize cases where we remove a page from the swapcache but > won't be able to reuse it, for example, because another process has it > mapped R/O, to not affect reclaim. > > We cannot easily handle the following cases and we will always have to > copy: > > (1) The page is referenced in the LRU pagevecs of other CPUs. We really > would have to drain the LRU pagevecs of all CPUs -- most probably > copying is much cheaper. > > (2) The page is already PageLRU() but is getting moved between LRU > lists, for example, for activation (e.g., mark_page_accessed()), > deactivation (MADV_COLD), or lazyfree (MADV_FREE). We'd have to > drain mostly unconditionally, which might be bad performance-wise. > Most probably this won't happen too often in practice. > > Note that there are other reasons why an anon page might temporarily not > be PageLRU(): for example, compaction and migration have to isolate LRU > pages from the LRU lists first (isolate_lru_page()), moving them to > temporary local lists and clearing PageLRU() and holding an additional > reference on the page. In that case, we'll always copy. > > This change seems to be fairly effective with the reproducer [1] shared > by Nadav, as long as writeback is done synchronously, for example, using > zram. However, with asynchronous writeback, we'll usually fail to free the > swapcache because the page is still under writeback: something we cannot > easily optimize for, and maybe it's not really relevant in practice. > > [1] https://lkml.kernel.org/r/0480D692-D9B2-429A-9A88-9BBA1331AC3A@gmail.com > > Signed-off-by: David Hildenbrand Acked-by: Vlastimil Babka