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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 035F5C433EF for ; Fri, 29 Apr 2022 01:57:59 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1354123AbiD2CBN (ORCPT ); Thu, 28 Apr 2022 22:01:13 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:36714 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1350360AbiD2CBK (ORCPT ); Thu, 28 Apr 2022 22:01:10 -0400 Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.220.29]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id A6B92BF526; Thu, 28 Apr 2022 18:57:54 -0700 (PDT) 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 4D1D11F891; Fri, 29 Apr 2022 01:57:53 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1651197473; 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=f6SWF/nGzhsjwq5ARATRVet+UBJFK9TgWKy2UT2xPXM=; b=U8L2w6H02ZPq7rqO5DJ0G2KO0ozM0gXG5jxSla0+RuSUHKTcGzpozSVMnFSJD5xmhDq8ad 2uyZ3apVsDcOxO6E8thPaHk3V8U3QwE2H7it2GRgun7Ft+q1sS0Y6dAuRBjTiqB4BbldL0 UKa0F/nGDA/bdxrLQvJ4wZUVWx6f5OA= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1651197473; 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=f6SWF/nGzhsjwq5ARATRVet+UBJFK9TgWKy2UT2xPXM=; b=y33957Ckvud8SaVQpfdx8Oo831Ez0W23CrChHWBUdp0Vg6adczUx3ofOTzcWn8qyMebGIp ebijTSE+d4Ipx8Bg== 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 35C8813446; Fri, 29 Apr 2022 01:57:50 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id x6U6OR5Ga2JHXgAAMHmgww (envelope-from ); Fri, 29 Apr 2022 01:57:50 +0000 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit MIME-Version: 1.0 From: "NeilBrown" To: "Andrew Morton" Cc: "Geert Uytterhoeven" , "Christoph Hellwig" , "Miaohe Lin" , linux-nfs@vger.kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH 1/2] MM: handle THP in swap_*page_fs() In-reply-to: <20220428182132.883a082ad8918fd5f8073130@linux-foundation.org> References: <165119280115.15698.2629172320052218921.stgit@noble.brown>, <165119301488.15698.9457662928942765453.stgit@noble.brown>, <20220428182132.883a082ad8918fd5f8073130@linux-foundation.org> Date: Fri, 29 Apr 2022 11:57:45 +1000 Message-id: <165119746546.1648.12856939779038565632@noble.neil.brown.name> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, 29 Apr 2022, Andrew Morton wrote: > On Fri, 29 Apr 2022 10:43:34 +1000 NeilBrown wrote: > > > Pages passed to swap_readpage()/swap_writepage() are not necessarily all > > the same size - there may be transparent-huge-pages involves. > > > > The BIO paths of swap_*page() handle this correctly, but the SWP_FS_OPS > > path does not. > > > > So we need to use thp_size() to find the size, not just assume > > PAGE_SIZE, and we need to track the total length of the request, not > > just assume it is "page * PAGE_SIZE". > > Cool. I added this in the series after > mm-submit-multipage-write-for-swp_fs_ops-swap-space.patch. I could > later squash it into that patch if you think that's more logical. I think it best to keep it separate, though that position is good. If we were to squash, some would need to go into the "submit multipage reads" patch, and some in "submit multipage writes". IF you wanted to do that I wouldn't object but I don't think it is needed. Thanks, NeilBrown