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 9CBAEC48BC3 for ; Mon, 19 Feb 2024 10:16:13 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 11EFE6B0075; Mon, 19 Feb 2024 05:16:13 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 0CD896B0078; Mon, 19 Feb 2024 05:16:13 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id ED7C06B007B; Mon, 19 Feb 2024 05:16:12 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id DB0AA6B0075 for ; Mon, 19 Feb 2024 05:16:12 -0500 (EST) Received: from smtpin09.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 9C2971202C7 for ; Mon, 19 Feb 2024 10:16:12 +0000 (UTC) X-FDA: 81808148184.09.9DB330D Received: from mail-yw1-f177.google.com (mail-yw1-f177.google.com [209.85.128.177]) by imf09.hostedemail.com (Postfix) with ESMTP id C42BB14000B for ; Mon, 19 Feb 2024 10:16:10 +0000 (UTC) Authentication-Results: imf09.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=FcvgNM72; spf=pass (imf09.hostedemail.com: domain of hughd@google.com designates 209.85.128.177 as permitted sender) smtp.mailfrom=hughd@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1708337770; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=nGxwSEo7jdD6QsMjGOSy8a5TjT863H0VEZLOli0MF44=; b=gPYa6c1nartjry6LH0pEKkyDIOm5E8EJeeY0lEp4OJAVDAbg3tDOzF2ha1KKHc/B/v9kXZ qAYTxdyaYUlrhKkpRtMYJUTkJDLPm2iQn+keWiGJwnxwshxlEt+YVMVS8YTKuyOoM4DQVw 6mGEfgSlHaKT8pG36/w0qr1VyM5DIG8= ARC-Authentication-Results: i=1; imf09.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=FcvgNM72; spf=pass (imf09.hostedemail.com: domain of hughd@google.com designates 209.85.128.177 as permitted sender) smtp.mailfrom=hughd@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1708337770; a=rsa-sha256; cv=none; b=wOf+H6ARilYsIbg7AK/+HZ3Mc7mw2vTYIauMgno35UYjPLC7nC7IFiwFJzb60zuKlmhKtD 2If6FzcvLsVfzd6TpXhPFxG8IlpGrCZ/RADOrkipnTXG3Ub/kfCwnib/ujMjZsBYrOGPWv 6pIjIG2XmaEx2PbZnYpkvonohFM0WiI= Received: by mail-yw1-f177.google.com with SMTP id 00721157ae682-6084c93f80eso2116907b3.3 for ; Mon, 19 Feb 2024 02:16:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1708337770; x=1708942570; darn=kvack.org; h=mime-version:references:message-id:in-reply-to:subject:cc:to:from :date:from:to:cc:subject:date:message-id:reply-to; bh=nGxwSEo7jdD6QsMjGOSy8a5TjT863H0VEZLOli0MF44=; b=FcvgNM72KW6nIh+p2PxD+Kd6Oss9sYB5y4mcvqhaESqQkN7EIClghZNTT0ACcwU9f4 901645bwvi4q4tLzNsqMQb81+C/Q4sI0246KNIjCTaYf61ZFjqYlYyoLUXmmDf1mgjuw N67iz6ryGgPIwTkH3ZbAT8+4dWDGOgc9A2ABMVO7gFOvHo/M5JAF1ndnEYzbtN0+LQeY 87CYadwhzXcUQjnDw8oH0ZnHLRMrhGoycn+YVNYXOrl+obN/IOSYTMnAd2Dqbw+Y9tYe FVkw67S30z3bvsHLko1AA+c2Jm/+9M++i7qsluBPG5hG+9wrW6i80qL5XBwZYh+VZBWZ AUgw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1708337770; x=1708942570; h=mime-version:references:message-id:in-reply-to:subject:cc:to:from :date:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=nGxwSEo7jdD6QsMjGOSy8a5TjT863H0VEZLOli0MF44=; b=Fcj0XR0xph94Rse78aYS7ruLS8bYFkZGfFaqnroj9MiIpnD43ofvNtbM8hWkmiF40K dy51FYXYk3GQfrXfyPnFe+aQiWcIf+/h3K+GZdkjlaWdQQ7aKIOOcluAxMIkiyQmcd8F 0HtBsNomfgE9PKGmW/k0iYKCKJMe6n2Kt89IKnLiIsuyiE9YvM/Pa+VoTFAMhZyxdRpf 6h2M0qqDDVhRKUoua8t7En59GRiGraBuxIKBfjOPazOaMEruqcVKL0RG/j9GKoIkSdOj DyLIKxzFX5cLRHPDkC594m9uBNpJrrJcVgbscVSIUiKvF8X4oaP8epdgcRGtyA55/7MF TsuA== X-Forwarded-Encrypted: i=1; AJvYcCWyXePZUTwUeX3TTGC+9WVdbKoEiIXpzTGrjozeGUvhOj1fcJH0EvKNydSpE0sBZjzcgAXkfZgaZGwPGe1AOaXmmP4= X-Gm-Message-State: AOJu0Yw/R6pWGappbPgA01Z+sXEdoURIAJnRM7s1mz2cyLxDIc7egQTS Fn+UieXThTBYocQYjUA+/MxGkgm4fTVK0aJKt+ur10VFv4Gfb3TT4TBujq5/xQ== X-Google-Smtp-Source: AGHT+IFJoAVuMYzdGhio7jIt4XIuZS5LYL15OslIBX+wn0f8UO4hUX2IbPCCvqiWaqIn1dV8z44Zlg== X-Received: by 2002:a81:431f:0:b0:608:e2f:e3d2 with SMTP id q31-20020a81431f000000b006080e2fe3d2mr4916030ywa.22.1708337769682; Mon, 19 Feb 2024 02:16:09 -0800 (PST) Received: from darker.attlocal.net (172-10-233-147.lightspeed.sntcca.sbcglobal.net. [172.10.233.147]) by smtp.gmail.com with ESMTPSA id dt15-20020a05690c250f00b00607f86fa184sm1476113ywb.99.2024.02.19.02.16.07 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 19 Feb 2024 02:16:08 -0800 (PST) Date: Mon, 19 Feb 2024 02:15:47 -0800 (PST) From: Hugh Dickins To: Daniel Gomez cc: "viro@zeniv.linux.org.uk" , "brauner@kernel.org" , "jack@suse.cz" , "hughd@google.com" , "akpm@linux-foundation.org" , "dagmcr@gmail.com" , "linux-fsdevel@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "linux-mm@kvack.org" , "willy@infradead.org" , "hch@infradead.org" , "mcgrof@kernel.org" , Pankaj Raghav , "gost.dev@samsung.com" Subject: Re: [RFC PATCH 0/9] shmem: fix llseek in hugepages In-Reply-To: <25i3n46nanffixvzdby6jwxgboi64qnleixz33dposwuwmzj7p@6yvgyakozars> Message-ID: References: <20240209142901.126894-1-da.gomez@samsung.com> <25i3n46nanffixvzdby6jwxgboi64qnleixz33dposwuwmzj7p@6yvgyakozars> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Rspamd-Queue-Id: C42BB14000B X-Rspam-User: X-Stat-Signature: r95do9py1bf1qb4pzti4q6n1zoeyts41 X-Rspamd-Server: rspam01 X-HE-Tag: 1708337770-898502 X-HE-Meta: U2FsdGVkX18SmATX8UmKIky/JhFmZaQiFBiKPW+De7y6B2oiaxLlqtCHzw/okvnoW7vbB9qzoGz6yqaowewYmf31GNNao8F2EqAXJhqeGB2D8bt1xWBlQZzaYdeGUTbOucz2+EWmCCBobPD4UET+n1X3MHCGWGUrlYEc5QCkiTVn8w8ZOiOkwcg6XVXMx530qRdWOifKqZnEgzcoYUd+OW3c+kGn8WCGwhvygYglRoOZgy5qsjdBDPED/Dowgkcdgc0XgEGMQ6794qpIhpnmdqieDO2jFZ1UhWRC1tHS6MfJTtDq2zmx1B/wGOBZRSktYsWp7HgHUYB9L1H4jk4aSjuvQd1Y50uAHnooQxG4fOiDn1lvZH3mUVwuX21TmwhxVeyDNLGEIn7pS3P/pip5bvRdYZ5NhaDL/8igAWH+QwZb1G19DlyJG7RQcy3bIASL1vKHh9Ic7Yd9h0h0d+mmo/nEdbi2pogQJtm2yJ2liOW0trL0uNRj/0vG+XXpvFP0DZef/+d6gpR98XzVP1DjDbEvGMIAyp3GgtN011cNh2Vbm/aU0Kic5TGzicTBYa2BgflmiaPNOF7pr+qBBRg/hfNcqdza1nreNXednXx41Z+Re2G5H40ZJYqFrVJGcNUA6wbM+32snrL5WDbvEuuPbgmZskWy161JAcJGp8WGZNtIwBD7xg5pYZC3d2h3QcrsdYjYI5OBakZiU54PSnmlF/+K+lfM1suCjntU11nzm86hgFn0mWV9uio6smjm4t1FXRWuDJ9eaY9K+5UzaqqDp3LNamaQ8q0fGmY8fwRyn7vmbvpf1WYNgjIRWdNw0rqQ9xTt8knTQTw8cYrY2F/bCYlmC6gbwZPJJ/Ch/FyySzD8SU9nGRX5o4Q05cShvHiPys7qcFPvz1z2Tk/YguQtUNAKEDl1NP5LNnOQjvm/YEIFnYjZiLHeR5OugGzgDbEABaMLsW01FDIqCZACjFt O3r/HhOP nGSAn98/yZy270UvIU14Mw0KflNqYHTtQmHG2LqXhvOYqENutu+RpEfohKF6SBUpEN+PFvsdF6R/e0H2z+GeJ9m6XbIg9P60ibndNbMxipxQY6cZXpOpBbNhxU+dufwPQzqhmWdtEOT09RmnZDtdUOmWuUuyMGdz86yXUxj1Xs2pSEnnuBDXeV5TIo/r3zTdkUFTS3vq1pvejLXCV4qmYknyTT6/bWtMZofAV/bjoNwpDdPcSMb1frSHVUxbrQ0LL8/QaH8PFP3L5VU0EAfmXKxrwAvhQs0WZHUJmg4J1HYucEkuBrlkjnp8TLsAFhSDm3b8gEf6d0nWZCY91F++FgJ20D0VTetCO1rOS8H9l23ZlhL5HYPV5U0IokgdDsFu9bicemZlK3qEO84bZ7D5eExnlgRu/lrcquGGCDJXw5FcpKdU= 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: List-Subscribe: List-Unsubscribe: On Wed, 14 Feb 2024, Daniel Gomez wrote: > On Fri, Feb 09, 2024 at 02:29:01PM +0000, Daniel Gomez wrote: > > Hi, > > > > The following series fixes the generic/285 and generic/436 fstests for huge > > pages (huge=always). These are tests for llseek (SEEK_HOLE and SEEK_DATA). > > > > The implementation to fix above tests is based on iomap per-block tracking for > > uptodate and dirty states but applied to shmem uptodate flag. > > Hi Hugh, Andrew, > > Could you kindly provide feedback on these patches/fixes? I'd appreciate your > input on whether we're headed in the right direction, or maybe not. I am sorry, Daniel, but I see this series as misdirected effort. We do not want to add overhead to tmpfs and the kernel, just to pass two tests which were (very reasonably) written for fixed block size, before the huge page possibility ever came in. If one opts for transparent huge pages in the filesystem, then of course the dividing line between hole and data becomes more elastic than before. It would be a serious bug if lseek ever reported an area of non-0 data as in a hole; but I don't think that is what generic/285 or generic/436 find. Beyond that, "man 2 lseek" is very forgiving of filesystem implementation. I'll send you my stack of xfstests patches (which, as usual, I cannot afford the time now to re-review and post): there are several tweaks to seek_sanity_test in there for tmpfs huge pages, along with other fixes for tmpfs (and some fixes to suit an old 32-bit build environment). With those tweaks, generic/285 and generic/436 and others (but not all) have been passing on huge tmpfs for several years. If you see something you'd like to add your name to in that stack, or can improve upon, please go ahead and post to the fstests list (Cc me). Thanks, Hugh > > Thanks, > Daniel > > > > > The motivation is to avoid any regressions in tmpfs once it gets support for > > large folios. > > > > Testing with kdevops > > Testing has been performed using fstests with kdevops for the v6.8-rc2 tag. > > There are currently different profiles supported [1] and for each of these, > > a baseline of 20 loops has been performed with the following failures for > > hugepages profiles: generic/080, generic/126, generic/193, generic/245, > > generic/285, generic/436, generic/551, generic/619 and generic/732. > > > > If anyone interested, please find all of the failures in the expunges directory: > > https://github.com/linux-kdevops/kdevops/tree/master/workflows/fstests/expunges/6.8.0-rc2/tmpfs/unassigned > > > > [1] tmpfs profiles supported in kdevops: default, tmpfs_noswap_huge_never, > > tmpfs_noswap_huge_always, tmpfs_noswap_huge_within_size, > > tmpfs_noswap_huge_advise, tmpfs_huge_always, tmpfs_huge_within_size and > > tmpfs_huge_advise. > > > > More information: > > https://github.com/linux-kdevops/kdevops/tree/master/workflows/fstests/expunges/6.8.0-rc2/tmpfs/unassigned > > > > All the patches has been tested on top of v6.8-rc2 and rebased onto latest next > > tag available (next-20240209). > > > > Daniel > > > > Daniel Gomez (8): > > shmem: add per-block uptodate tracking for hugepages > > shmem: move folio zero operation to write_begin() > > shmem: exit shmem_get_folio_gfp() if block is uptodate > > shmem: clear_highpage() if block is not uptodate > > shmem: set folio uptodate when reclaim > > shmem: check if a block is uptodate before splice into pipe > > shmem: clear uptodate blocks after PUNCH_HOLE > > shmem: enable per-block uptodate > > > > Pankaj Raghav (1): > > splice: don't check for uptodate if partially uptodate is impl > > > > fs/splice.c | 17 ++- > > mm/shmem.c | 340 ++++++++++++++++++++++++++++++++++++++++++++++++---- > > 2 files changed, 332 insertions(+), 25 deletions(-) > > > > -- > > 2.43.0