Received: by 2002:a05:6a10:1a4d:0:0:0:0 with SMTP id nk13csp5551050pxb; Mon, 14 Feb 2022 01:38:22 -0800 (PST) X-Google-Smtp-Source: ABdhPJy0IYMXEntdlNZfcgCZJLkazCXmdbFWm8awQ6XAfqcPQgwB166YjWM1keDm0ixJ9TY0VcCe X-Received: by 2002:a05:6402:5113:: with SMTP id m19mr14357369edd.325.1644831502638; Mon, 14 Feb 2022 01:38:22 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1644831502; cv=none; d=google.com; s=arc-20160816; b=sLai20MTutHbii9A9S1eaTeEHgtFvA23n/TEFaAg5KkjwJJyqH52citvov+Cyo4HcK y1LBgSvUbOUY1aeBjtkW/K2tkaFeEwrbDANt4nVhLFuyoGjvrh4vYM4jkdehsTGw7tl7 W7OM3HHKDq2mlh6gsXe+dbeWOfi00N0EkHEIQjyrsqUQf62H9dTVMuiPV+hszq0bixu2 nn5g0vowh8bIOqfOToKRMjifVCd+2PP1D7zjRgYSyTdJajFNmyEgmE+JTvstCvORcmqi qf2fEmzPQEWPnPHtaDbMOJKkCgZOaPLN5+Qj6aZV7gtgsMi8Vb9IEAr/AtOD2MADyPV4 Jxqw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:in-reply-to:from :references:cc:to:content-language:subject:user-agent:mime-version :date:message-id:dkim-signature:dkim-signature; bh=uILjlSDN1FN8OOLhjeaE5XGyYvqt6MKuWO5g9cvdqUI=; b=hQZt1IQps4ivGSOjusE0D4JkjJvBdT6zo+pn2VVDboNRd0jqz8ABMnqM7hcIZeZYzI NKLLOf5qiPqyntbvLKq/odvNx32D4KS8SsiJteHmYI8gkfmeEEpRtZW/CRnNBXXnctGl +mB/FmglW4C3/q9DJKaOXZau8bM8CDQ7qfhuBldzftZRa9kZuomUI2OmLBp7L5OZ0gKd bJgiaFJL3jCLai4C6m4GpbMZl2wM08sj6boT2LnBamvIUvlu4DVEVaDg/LcCW8RhJ0DX rk6TKmrbKfODgQK0k2j7hclUs1IStYBkiv0CksrfUkoAFjW3GoMmEDXSO6COUJc8mLwV 9GZw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@suse.cz header.s=susede2_rsa header.b=cnkiRgwT; dkim=neutral (no key) header.i=@suse.cz header.s=susede2_ed25519 header.b=Wd1WNoDq; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id ji12si11746673ejc.799.2022.02.14.01.37.58; Mon, 14 Feb 2022 01:38:22 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@suse.cz header.s=susede2_rsa header.b=cnkiRgwT; dkim=neutral (no key) header.i=@suse.cz header.s=susede2_ed25519 header.b=Wd1WNoDq; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1352010AbiBKRTo (ORCPT + 93 others); Fri, 11 Feb 2022 12:19:44 -0500 Received: from mxb-00190b01.gslb.pphosted.com ([23.128.96.19]:40808 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S244536AbiBKRTm (ORCPT ); Fri, 11 Feb 2022 12:19:42 -0500 Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.220.29]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 6E22C95 for ; Fri, 11 Feb 2022 09:19:41 -0800 (PST) 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 0ED1F1F3AA; Fri, 11 Feb 2022 17:19:40 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_rsa; t=1644599980; 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=uILjlSDN1FN8OOLhjeaE5XGyYvqt6MKuWO5g9cvdqUI=; b=cnkiRgwT+qCMYd/sM4tBXGuCaPvNwTUHOCuk377e+Ms6STQjzR2ByZIyLm6hgriLLsg7wB L+u5r7awJjmgYs1MOYkOgyeIsKLevomq/XAtyR2GxG8s2JkUX7TfUBOXqURzowofLSgsgV pwSSHfJSV9b1ydfntC1F+zOtvXNvKrk= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_ed25519; t=1644599980; 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=uILjlSDN1FN8OOLhjeaE5XGyYvqt6MKuWO5g9cvdqUI=; b=Wd1WNoDqiOq4dCFsftayNEyUQ1Z2lq5wdTS3VAaBXv+sWHUpRKGObnFileZh1OXJp+CF0z nomQ+z/bYDQ26NCQ== 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 BD6E713C97; Fri, 11 Feb 2022 17:19:39 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id LWGdLauaBmKfBwAAMHmgww (envelope-from ); Fri, 11 Feb 2022 17:19:39 +0000 Message-ID: <8a974112-bfa8-7c48-e429-4ad5ec8e5ac4@suse.cz> Date: Fri, 11 Feb 2022 18:19:39 +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 08/13] mm/migrate: __unmap_and_move() push good newpage to LRU 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> <33fb71cf-ea55-123a-bf9d-fdad297cae1@google.com> From: Vlastimil Babka In-Reply-To: <33fb71cf-ea55-123a-bf9d-fdad297cae1@google.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.8 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,NICE_REPLY_A,RCVD_IN_DNSWL_LOW, SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2/6/22 22:43, Hugh Dickins wrote: > Compaction, NUMA page movement, THP collapse/split, and memory failure > do isolate unevictable pages from their "LRU", losing the record of > mlock_count in doing so (isolators are likely to use page->lru for their > own private lists, so mlock_count has to be presumed lost). > > That's unfortunate, and we should put in some work to correct that: one > can imagine a function to build up the mlock_count again - but it would > require i_mmap_rwsem for read, so be careful where it's called. Or > page_referenced_one() and try_to_unmap_one() might do that extra work. > > But one place that can very easily be improved is page migration's > __unmap_and_move(): a small adjustment to where the successful new page > is put back on LRU, and its mlock_count (if any) is built back up by > remove_migration_ptes(). > > Signed-off-by: Hugh Dickins Acked-by: Vlastimil Babka > --- > mm/migrate.c | 31 +++++++++++++++++++------------ > 1 file changed, 19 insertions(+), 12 deletions(-) > > diff --git a/mm/migrate.c b/mm/migrate.c > index 7c4223ce2500..f4bcf1541b62 100644 > --- a/mm/migrate.c > +++ b/mm/migrate.c > @@ -1032,6 +1032,21 @@ static int __unmap_and_move(struct page *page, struct page *newpage, > if (!page_mapped(page)) > rc = move_to_new_page(newpage, page, mode); > > + /* > + * When successful, push newpage to LRU immediately: so that if it > + * turns out to be an mlocked page, remove_migration_ptes() will > + * automatically build up the correct newpage->mlock_count for it. > + * > + * We would like to do something similar for the old page, when > + * unsuccessful, and other cases when a page has been temporarily > + * isolated from the unevictable LRU: but this case is the easiest. > + */ > + if (rc == MIGRATEPAGE_SUCCESS) { > + lru_cache_add(newpage); > + if (page_was_mapped) > + lru_add_drain(); > + } > + > if (page_was_mapped) > remove_migration_ptes(page, > rc == MIGRATEPAGE_SUCCESS ? newpage : page, false); > @@ -1045,20 +1060,12 @@ static int __unmap_and_move(struct page *page, struct page *newpage, > unlock_page(page); > out: > /* > - * If migration is successful, decrease refcount of the newpage > + * If migration is successful, decrease refcount of the newpage, > * which will not free the page because new page owner increased > - * refcounter. As well, if it is LRU page, add the page to LRU > - * list in here. Use the old state of the isolated source page to > - * determine if we migrated a LRU page. newpage was already unlocked > - * and possibly modified by its owner - don't rely on the page > - * state. > + * refcounter. > */ > - if (rc == MIGRATEPAGE_SUCCESS) { > - if (unlikely(!is_lru)) > - put_page(newpage); > - else > - putback_lru_page(newpage); > - } > + if (rc == MIGRATEPAGE_SUCCESS) > + put_page(newpage); > > return rc; > }