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 6875DEED60B for ; Fri, 15 Sep 2023 15:41:13 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id F32DF6B037F; Fri, 15 Sep 2023 11:41:12 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id EE2A26B0380; Fri, 15 Sep 2023 11:41:12 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id DAAB36B0381; Fri, 15 Sep 2023 11:41:12 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id C9A966B037F for ; Fri, 15 Sep 2023 11:41:12 -0400 (EDT) Received: from smtpin21.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 97EE2120799 for ; Fri, 15 Sep 2023 15:41:12 +0000 (UTC) X-FDA: 81239245584.21.311BBA6 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf29.hostedemail.com (Postfix) with ESMTP id CF980120021 for ; Fri, 15 Sep 2023 15:41:10 +0000 (UTC) Authentication-Results: imf29.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=LiB16jYT; dmarc=none; spf=none (imf29.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1694792470; 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=ynT1nLavvHmZ9Y3KmC8cEJGBrfw6nFzCLS4ybzmu8CI=; b=MmKBw1Cq5abmu5Tly7IJgAgemEIivu7LUod5R/v0SObyjo1LPrVX0GdR+nS5zUnBQxaUuv rmQArY+hVFFekiNx217lJuIqW8rbHBTUbPpaV7u8WPPIlORigKJPcTCqiBwY5v6aAVLAGV jELdByAHwHMS1Dt8VbehW/SZmDp+QnA= ARC-Authentication-Results: i=1; imf29.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=LiB16jYT; dmarc=none; spf=none (imf29.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1694792470; a=rsa-sha256; cv=none; b=ACc7YtMCzcGxTpJSZBE2/hxqHiVRw9CFrjl4uNDynyNRHwcKnxOjE6co/tn+/pRE9uNHNk i5ei2C/j6M1v1LjaIn95YGsY++FMNAcl3xC20tqiO926t0OBNk52KQeITWz9L0xh0ve0p2 mFN9nOKAlxzYYShQJnrc2tYjpPEo82U= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=ynT1nLavvHmZ9Y3KmC8cEJGBrfw6nFzCLS4ybzmu8CI=; b=LiB16jYTkCJkA/Ev76u4JJuDY6 L7IDRqRgcgjkVp76JL9fktoTVPA9u0sAyvGaZX8A8K/ju+OcT8pWv28oMtxf17xXvtled4yuHA3ZZ an1KyUV184vlKwtURQSshBebJwypj5jEtJfcSc5WadN1mywYPQ8rmh9oYbZTvSbBKHF4eMj3J3oFL qaJXN+M6e/cjcl8/vg5YWF3sYkvaV32MOH3mZoq9VpW6rKio9NYd/DPu5nIOgbs8vWfk2g9dpyU1l dUVn4x+OmUsHm2XZ76jXaBiSEMMkOOnrH6wVii6yIA6YTxw4nAUDJTUAqCSQcUDl1QLr4EyBmL8TR tXm4OiZA==; Received: from willy by casper.infradead.org with local (Exim 4.94.2 #2 (Red Hat Linux)) id 1qhAwF-00AZVJ-Q8; Fri, 15 Sep 2023 15:40:59 +0000 Date: Fri, 15 Sep 2023 16:40:59 +0100 From: Matthew Wilcox To: David Hildenbrand Cc: Daniel Gomez , "minchan@kernel.org" , "senozhatsky@chromium.org" , "axboe@kernel.dk" , "djwong@kernel.org" , "hughd@google.com" , "akpm@linux-foundation.org" , "mcgrof@kernel.org" , "linux-kernel@vger.kernel.org" , "linux-block@vger.kernel.org" , "linux-xfs@vger.kernel.org" , "linux-fsdevel@vger.kernel.org" , "linux-mm@kvack.org" , "gost.dev@samsung.com" , Pankaj Raghav Subject: Re: [PATCH 0/6] shmem: high order folios support in write path Message-ID: References: <20230915095042.1320180-1-da.gomez@samsung.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: CF980120021 X-Rspam-User: X-Rspamd-Server: rspam02 X-Stat-Signature: 1hfbdm9cccm5yf8bahff3d5pydy55xq1 X-HE-Tag: 1694792470-426857 X-HE-Meta: U2FsdGVkX19O83zERLRHM1ReH4yd6LM73D1fBhqo8gf3RAgojJCxwPJI3dY8EZuV+K+bn+7tkKO9DICbX1u0TR38l9L7meZvy9wdGecbbftYq5cUZyL4P399nJLfFqxoWvd3Wz+ORZLCLxqu2ggU6IPyPwIr3JS/57Da2Ke9eS9ibJ32fX3gTXngTbP0xVj43keK5muJgYC/pLYSAxe+D5pQnSk/fJ0REoU1j+Et1iLNQbPRmZcgvgtnpbfzfssGiF4GhjgfMiNLE9BgGd2oiTSmJ0jlB9Z77ZmKthIx/PfyLT+gJUtvjOzGrHUPvXMNPXcI9QoaGb5gWx5UCv+PKGUOb5ED/W6+bVtlBSyrDj/dmdneZ0hknDXGso8KS+sVzGjG3wZaunW07q3TS+iQBVXGvRTmGWlHK5RSflHBj5oXo2ZSLhHRGo3akCpchjjK0ufd5b6pX33KNORH5v8D63EFSOyG5h7oxlI/F64eEdLikTC1fpE3ywGpsbyQ2zDEe3LaaPStYGg3hFtcDkzf9eoCJP7qKPq3fMja3/PMijYFwiFep+tDtrmSX3Gmc2rKTlIC7UaFmrhoMpXN65wY22atLokqAOicI1iwJ4WDWq3ryx7DtV/ChX03qq4ChHe2OJ16O7aLWH8VZuDMYd30CUJ80903CZiuhe/OEtjMZWW02Bzo0C9aGx24lrFNGn+CCPiyuLxgG3wfKSZB0IOv8+ZykhSmPs55ik/0vcJVafj7qgsWVuVNcANJxWpE9hUmCsq8ejFwnJwp59aORkCqXo4RRVEPgOdUQ2cTGs90hQ1DLuuWb3rO7GVmTaDWZez7AoKVW+FEV3JOGiW8FBlNv3GVM4xCa0aZZoNGcQF2NWjAoPUtSXI7/PTnEJdvhqvPdc4flNVSzXp5UYozKW8numyCmbzv742/zD5wpXHFgGUTKPVf0v6PTwjl6HDrtcCgKPOSqobqjhgJWN8yrBm J4P2CPfv +i1D9P4qvAZ5R7P9oHraC9NbrfMor92Qwe/OxxKue0GEt2AtoyqNbvzo2tNTGwhSNx3pC5ArxZV1i9qH6otQ7quRE08AJS+ly37MB1HhkMQ90l0TobngyzSIIOacE+zcn8Z+2hx3q0FA7QGrtJ4ug9K4rXmpS+ccWob2wqq5mqu3TgVOzUAxp02ASpw== 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, Sep 15, 2023 at 05:36:27PM +0200, David Hildenbrand wrote: > On 15.09.23 17:34, Matthew Wilcox wrote: > > No, it can't. This patchset triggers only on write, not on read or page > > fault, and it's conservative, so it will only allocate folios which are > > entirely covered by the write. IOW this is memory we must allocate in > > order to satisfy the write; we're just allocating it in larger chunks > > when we can. > > Oh, good! I was assuming you would eventually over-allocate on the write > path. We might! But that would be a different patchset, and it would be subject to its own discussion. Something else I've been wondering about is possibly reallocating the pages on a write. This would apply to both normal files and shmem. If you read in a file one byte at a time, then overwrite a big chunk of it with a large single write, that seems like a good signal that maybe we should manage that part of the file as a single large chunk instead of individual pages. Maybe. Lots of things for people who are obsessed with performance to play with ;-)