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 DB594C77B60 for ; Fri, 31 Mar 2023 22:04:37 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id C16946B0072; Fri, 31 Mar 2023 18:04:36 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id BC7286B0074; Fri, 31 Mar 2023 18:04:36 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A8E986B0075; Fri, 31 Mar 2023 18:04:36 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 8AE1E6B0072 for ; Fri, 31 Mar 2023 18:04:36 -0400 (EDT) Received: from smtpin23.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 5EBC5160323 for ; Fri, 31 Mar 2023 22:04:36 +0000 (UTC) X-FDA: 80630573352.23.8403E8B Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by imf05.hostedemail.com (Postfix) with ESMTP id 8DB92100008 for ; Fri, 31 Mar 2023 22:04:34 +0000 (UTC) Authentication-Results: imf05.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=korg header.b=vs6Lz4cA; dmarc=none; spf=pass (imf05.hostedemail.com: domain of akpm@linux-foundation.org designates 145.40.68.75 as permitted sender) smtp.mailfrom=akpm@linux-foundation.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1680300274; 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=sC9KN2RKkXadBsDx3V19qiDGy6Qklf9zIf+ThKaBq1s=; b=r2gajnbt7cTFlwb4D0oNCEKLLzcEBIQKMOl1ZAnzlMIc/Jq+gqXnWSisiUzKmgellwhxkC +9vyuIa+W8pjKT65YEykxnnRNsdoM4DJMfFtqbaUI6xL0FxDQkSHodV2LOzNBzspxClHdG BhHpCe8Iyu7NS84NBz9oFF9b8z4N+8M= ARC-Authentication-Results: i=1; imf05.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=korg header.b=vs6Lz4cA; dmarc=none; spf=pass (imf05.hostedemail.com: domain of akpm@linux-foundation.org designates 145.40.68.75 as permitted sender) smtp.mailfrom=akpm@linux-foundation.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1680300274; a=rsa-sha256; cv=none; b=oF/LctO33th/HySPB9YWR0waY+ksm11Gi7axVpywdd/h/NWWIUR/SU/7rDamxS2qRky6Tj oebFssFcxE3SCyFReYIkBUrCY25xPuPguC3XlJxF/pndlAIAk8WiScWmlYbiEmQCA2+IO/ R9YOekjW2qygAPArikKDpQ0uIXs0WZ8= Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 9015DB83259; Fri, 31 Mar 2023 22:04:32 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 0F77FC433D2; Fri, 31 Mar 2023 22:04:31 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linux-foundation.org; s=korg; t=1680300271; bh=y75tzqtO/00AP4h3NcC3yhpaClgjp49viV/Jpgl25Gc=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=vs6Lz4cAD8QohfCI437uO557Vnvq0b76OWFRvJsAKCHGygOsdzzGReFzksV2buL80 IHi8KOP1IFpIlRbVJrWEZuv3VitjFuV0Hj64kw1dokZLWh9Gq4bPOQ7hpjnCTQA382 ex71kxhcZ2X+w+BMMWP0+1G9c6+RY5vpRDAogG8I= Date: Fri, 31 Mar 2023 15:04:30 -0700 From: Andrew Morton To: Qi Zheng Cc: willy@infradead.org, lstoakes@gmail.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH 1/2] mm: swap: use folio_batch_reinit() in folio_batch_move_lru() Message-Id: <20230331150430.546de954b0a7918f042c562e@linux-foundation.org> In-Reply-To: <20230331095858.51810-1-zhengqi.arch@bytedance.com> References: <20230331095858.51810-1-zhengqi.arch@bytedance.com> X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 8DB92100008 X-Rspamd-Server: rspam09 X-Rspam-User: X-Stat-Signature: ap9nrj4o1om3wy6bb7ifokfg6nmi5dy6 X-HE-Tag: 1680300274-355676 X-HE-Meta: U2FsdGVkX1/q8gKoFOrM5KupAxFFs2gWAEW13F/e+0uWNZ0L9psE6Kqq++rTIGnA+qoeDNm1bN/tf67JbC+hRAcdCQ9KZVxkP9CQbO+3S8Q6669KlRqjtC5Psf9meL7aC4v0caNmtZGSy9vwwHKdS0Ol8304AljHnMS3FiOxPPSGBMngc0niG0swhVTUI1g3IHlhlVpMXpY5iYq3Wt36kHXqYaguKQhQGpTtZnXYSTuW8TyCJCdnbMxp8+fdx/fg2VQuQplWpf0OLTPoYwqp7cnmv9wKFHEwvsTCU1Yads5IOwng+5AVCcpEb+A7LgnljKHgxhxZ+1asG6f/FkF5jX9hFtBBa4f4CEo2ER/CiBp8sJ8ndvUkEJg3/qzVoUqm9eOfrOa6QGIUjiwWaFOoFd3KRUh0rYFgjG7jXRVtaG2wjpV3YOuRUY08snklqiVkj3wiNh//GlEGa9e6IkzjvSA+UEuf+QsNDK9iqTswI9Z+rRZ8z9e0cyFmAsxQmzxPygNZmWLq/1edFq8DrwsM6JJQv652Te2MCnDeO9igNpdcEf1jb/ORNI8as+PZx18JHkIDro1XQskCEsxdRRd3Zg7+1gIMtAR6k1EUBrgDWDqxzD3GazqJGyUs0KJC8K+IqKfaxatH8SO2R1HCStGajnlljv/J85WuwlLwbi8q+cm4yiEDtcujBJ92+O5BoMQgLSG381s8QLnfWUWu2oSytRVRZRQqrAOZ4KCJ0fVSQ5yg+zeuppI5PV6snXnWDKd7VDS//ZC6LZx7Zn2n3DrqsBvyT9S/wsAFotoekvQtqb1QAeWEyVUX6JU2YKO0+M9rMvCzKsb6giQ9yXzgkAssYcQxFjkqMDXjjAR3D91b3YSvdr8thYed92M91Hx7HcGchhC+8PinmMKRMU6bTGtmq2YIkUbG9vU1t85IDARk/X8z94KFZ1vqaluoh7LOJD90rn0xlp1RKex3xbsigd1 h4q/J9Bc ars/ilxJ7sYd81qD9/J8Fqdh1tUrVl1D/lPP1REyNT8ZTiG/+nUHUxpnrsZdAsP+xoua7pz9a+lRJzYsiKPa1QPUfGdjgFTNe0P7icxdeENUHx2ocUsTk5iOuBWyeo+L62Y4cLiK6nlxvHGU6ib69Ytsa+K0A3atTBazQSKN/tHCxUXuvFoiD/i3jsaGVPUhLG3Uw4/8kwQsE+ojXmstJNjaqiQkfSht7tnr71j48iPIrbb7AdOYzSt3PuvHkZeCqBl6Je4D4q/L7/AFSh2JmPQt7tQ== 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 Fri, 31 Mar 2023 17:58:57 +0800 Qi Zheng wrote: > In folio_batch_move_lru(), the folio_batch is not freshly > initialised, so it should call folio_batch_reinit() as > pagevec_lru_move_fn() did before. > > ... > > --- a/mm/swap.c > +++ b/mm/swap.c > @@ -222,7 +222,7 @@ static void folio_batch_move_lru(struct folio_batch *fbatch, move_fn_t move_fn) > if (lruvec) > unlock_page_lruvec_irqrestore(lruvec, flags); > folios_put(fbatch->folios, folio_batch_count(fbatch)); > - folio_batch_init(fbatch); > + folio_batch_reinit(fbatch); > } > > static void folio_batch_add_and_move(struct folio_batch *fbatch, Well... why? This could leave the kernel falsely thinking that the folio's pages have been drained from the per-cpu LRU addition magazines. Maybe that's desirable, maybe not, but I think this change needs much much more explanation describing why it is beneficial. folio_batch_reinit() seems to be a custom thing for the mlock code - perhaps it just shouldn't exist, and its operation should instead be open-coded in mlock_folio_batch(). The dynamics and rules around ->percpu_pvec_drained are a bit mysterious. A code comment which explains all of this would be useful.