From patchwork Sun Mar 6 22:59:05 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Hugh Dickins X-Patchwork-Id: 12770951 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 3AF55C433F5 for ; Sun, 6 Mar 2022 22:59:10 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id B849C8D0002; Sun, 6 Mar 2022 17:59:09 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id B0E118D0001; Sun, 6 Mar 2022 17:59:09 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 95F5C8D0002; Sun, 6 Mar 2022 17:59:09 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0250.hostedemail.com [216.40.44.250]) by kanga.kvack.org (Postfix) with ESMTP id 7FFFD8D0001 for ; Sun, 6 Mar 2022 17:59:09 -0500 (EST) Received: from smtpin30.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id 216D2181CB2A9 for ; Sun, 6 Mar 2022 22:59:09 +0000 (UTC) X-FDA: 79215478818.30.6A74D94 Received: from mail-oi1-f181.google.com (mail-oi1-f181.google.com [209.85.167.181]) by imf04.hostedemail.com (Postfix) with ESMTP id 9BE0440004 for ; Sun, 6 Mar 2022 22:59:08 +0000 (UTC) Received: by mail-oi1-f181.google.com with SMTP id 12so13474136oix.12 for ; Sun, 06 Mar 2022 14:59:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=date:from:to:cc:subject:in-reply-to:message-id:references :mime-version; bh=kuAwFNdvfUoB+jhabmE+ejZcyF5svphRQA7Cw43kwi8=; b=kPpUrffhO4TxCVaOXzvYs3e+cRGTHM3KtZ7WfofY+N2dasiK1j/6xoWwLR2tAm09KP mebxc6zSJHXoGueC47+fk0VBombrG/KE4uWHWY1VJhkV50ZNt525Cds4bc+B/USeEcG7 FIHMN5Hvi+uN4TskszrITE8f5QC/SJqiuC/FeXphySHlXyGsD4Iu9boUgR5OXeE9FWf8 3LXroc8K5k3cLjEyDk/dp+yW6EvpFaIggjg6OHx66pO6L76jeZLWAcdg8fK3AuISQl/y JXmV3xxAcUXzM6hXZRv7rdyt7uHpCNKZMqXbOa+l5A4VdxulEsmI5VwOHylGRJjlwwfw E+nA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:in-reply-to:message-id :references:mime-version; bh=kuAwFNdvfUoB+jhabmE+ejZcyF5svphRQA7Cw43kwi8=; b=TjyO+dwy0WS05uxDGdmGzi/jOAdjgxMuG1iQVmLuuIwfllzRElOhrv0a16gf4Aiztb oRrp9zc+vz/t7vj2RC0mP5Fac4JD0FO286JaNk5zuiEN1YbfQ9dXer8LT40F9KoKoGYl JogVhcPxhfDbyTAal9PqURwZtd6fyxAIfcF3g6o+QLHeGolzSLRKAie297kVAgY8/cTZ sXVcBELNWw48Pbcarj2MVXbD3mcAIVqqguvyyjW9xFfYD7Rn0h5oY8b9s5o2+4Lt96sx rMg0ATJyzdYOZoyfREyvNbt0BY38HeP+QwMwi2ri8+K4q9eHXC9k+Fy4RrhojghqNQ6n gUzw== X-Gm-Message-State: AOAM531UoE7WuC8M6R+075RCp4Ciyp9BQGIQsllnKp1/VlQ9bSHUMW8K mfBlaWU+99klo+nnWbEf1M2P5Q== X-Google-Smtp-Source: ABdhPJx/Hqu7SfzlGzmEpo8d7O7y359VqM5bOvt1wDfmQObfLuYDP6UYX4MMELpvv/a9avdsR+wwjQ== X-Received: by 2002:a05:6808:18a7:b0:2d4:6a7e:23e6 with SMTP id bi39-20020a05680818a700b002d46a7e23e6mr5771492oib.152.1646607547846; Sun, 06 Mar 2022 14:59:07 -0800 (PST) Received: from ripple.attlocal.net (172-10-233-147.lightspeed.sntcca.sbcglobal.net. [172.10.233.147]) by smtp.gmail.com with ESMTPSA id 67-20020aca0746000000b002d71928659dsm5586722oih.8.2022.03.06.14.59.06 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 06 Mar 2022 14:59:07 -0800 (PST) Date: Sun, 6 Mar 2022 14:59:05 -0800 (PST) From: Hugh Dickins X-X-Sender: hugh@ripple.anvils To: Andrew Morton cc: Hugh Dickins , Christoph Hellwig , Mikulas Patocka , Zdenek Kabelac , Lukas Czerner , "Darrick J. Wong" , Miklos Szeredi , Borislav Petkov , linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org Subject: [PATCH mmotm v2] tmpfs: do not allocate pages on read In-Reply-To: <20220306092709.GA22883@lst.de> Message-ID: <90bc5e69-9984-b5fa-a685-be55f2b64b@google.com> References: <20220306092709.GA22883@lst.de> MIME-Version: 1.0 X-Rspam-User: X-Rspamd-Server: rspam02 X-Rspamd-Queue-Id: 9BE0440004 X-Stat-Signature: 1qobtptmawzh5qexskqa1w79odif8y43 Authentication-Results: imf04.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=kPpUrffh; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf04.hostedemail.com: domain of hughd@google.com designates 209.85.167.181 as permitted sender) smtp.mailfrom=hughd@google.com X-HE-Tag: 1646607548-769422 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: Mikulas asked in https://lore.kernel.org/linux-mm/alpine.LRH.2.02.2007210510230.6959@file01.intranet.prod.int.rdu2.redhat.com/ Do we still need a0ee5ec520ed ("tmpfs: allocate on read when stacked")? Lukas noticed this unusual behavior of loop device backed by tmpfs in https://lore.kernel.org/linux-mm/20211126075100.gd64odg2bcptiqeb@work/ Normally, shmem_file_read_iter() copies the ZERO_PAGE when reading holes; but if it looks like it might be a read for "a stacking filesystem", it allocates actual pages to the page cache, and even marks them as dirty. And reads from the loop device do satisfy the test that is used. This oddity was added for an old version of unionfs, to help to limit its usage to the limited size of the tmpfs mount involved; but about the same time as the tmpfs mod went in (2.6.25), unionfs was reworked to proceed differently; and the mod kept just in case others needed it. Do we still need it? I cannot answer with more certainty than "Probably not". It's nasty enough that we really should try to delete it; but if a regression is reported somewhere, then we might have to revert later. It's not quite as simple as just removing the test (as Mikulas did): xfstests generic/013 hung because splice from tmpfs failed on page not up-to-date and page mapping unset. That can be fixed just by marking the ZERO_PAGE as Uptodate, which of course it is: do so in pagecache_init() - it might be useful to others than tmpfs. My intention, though, was to stop using the ZERO_PAGE here altogether: surely iov_iter_zero() is better for this case? Sadly not: it relies on clear_user(), and the x86 clear_user() is slower than its copy_user(): https://lore.kernel.org/lkml/2f5ca5e4-e250-a41c-11fb-a7f4ebc7e1c9@google.com/ But while we are still using the ZERO_PAGE, let's stop dirtying its struct page cacheline with unnecessary get_page() and put_page(). Reported-by: Mikulas Patocka Reported-by: Lukas Czerner Signed-off-by: Hugh Dickins Reviewed-by: Christoph Hellwig Acked-by: Darrick J. Wong --- v2: Set ZERO_PAGE uptodate during init, per hch. mm/filemap.c | 6 ++++++ mm/shmem.c | 20 ++++++-------------- 2 files changed, 12 insertions(+), 14 deletions(-) --- a/mm/filemap.c +++ b/mm/filemap.c @@ -1063,6 +1063,12 @@ void __init pagecache_init(void) init_waitqueue_head(&folio_wait_table[i]); page_writeback_init(); + + /* + * tmpfs uses the ZERO_PAGE for reading holes: it is up-to-date, + * and splice's page_cache_pipe_buf_confirm() needs to see that. + */ + SetPageUptodate(ZERO_PAGE(0)); } /* diff --git a/mm/shmem.c b/mm/shmem.c index 3c346f2e557f..659bd599d731 100644 --- a/mm/shmem.c +++ b/mm/shmem.c @@ -2501,19 +2501,10 @@ static ssize_t shmem_file_read_iter(struct kiocb *iocb, struct iov_iter *to) struct address_space *mapping = inode->i_mapping; pgoff_t index; unsigned long offset; - enum sgp_type sgp = SGP_READ; int error = 0; ssize_t retval = 0; loff_t *ppos = &iocb->ki_pos; - /* - * Might this read be for a stacking filesystem? Then when reading - * holes of a sparse file, we actually need to allocate those pages, - * and even mark them dirty, so it cannot exceed the max_blocks limit. - */ - if (!iter_is_iovec(to)) - sgp = SGP_CACHE; - index = *ppos >> PAGE_SHIFT; offset = *ppos & ~PAGE_MASK; @@ -2522,6 +2513,7 @@ static ssize_t shmem_file_read_iter(struct kiocb *iocb, struct iov_iter *to) pgoff_t end_index; unsigned long nr, ret; loff_t i_size = i_size_read(inode); + bool got_page; end_index = i_size >> PAGE_SHIFT; if (index > end_index) @@ -2532,15 +2524,13 @@ static ssize_t shmem_file_read_iter(struct kiocb *iocb, struct iov_iter *to) break; } - error = shmem_getpage(inode, index, &page, sgp); + error = shmem_getpage(inode, index, &page, SGP_READ); if (error) { if (error == -EINVAL) error = 0; break; } if (page) { - if (sgp == SGP_CACHE) - set_page_dirty(page); unlock_page(page); if (PageHWPoison(page)) { @@ -2580,9 +2570,10 @@ static ssize_t shmem_file_read_iter(struct kiocb *iocb, struct iov_iter *to) */ if (!offset) mark_page_accessed(page); + got_page = true; } else { page = ZERO_PAGE(0); - get_page(page); + got_page = false; } /* @@ -2595,7 +2586,8 @@ static ssize_t shmem_file_read_iter(struct kiocb *iocb, struct iov_iter *to) index += offset >> PAGE_SHIFT; offset &= ~PAGE_MASK; - put_page(page); + if (got_page) + put_page(page); if (!iov_iter_count(to)) break; if (ret < nr) {