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 6A4E1C7618A for ; Mon, 20 Mar 2023 13:58:48 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id E45DD6B0074; Mon, 20 Mar 2023 09:58:47 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id DF5E36B0075; Mon, 20 Mar 2023 09:58:47 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id CBED56B0078; Mon, 20 Mar 2023 09:58:47 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id BB80F6B0074 for ; Mon, 20 Mar 2023 09:58:47 -0400 (EDT) Received: from smtpin26.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 54AD040D38 for ; Mon, 20 Mar 2023 13:58:45 +0000 (UTC) X-FDA: 80589432210.26.3DD2083 Received: from verein.lst.de (verein.lst.de [213.95.11.211]) by imf26.hostedemail.com (Postfix) with ESMTP id 55C86140003 for ; Mon, 20 Mar 2023 13:58:43 +0000 (UTC) Authentication-Results: imf26.hostedemail.com; dkim=none; dmarc=none; spf=none (imf26.hostedemail.com: domain of hch@lst.de has no SPF policy when checking 213.95.11.211) smtp.mailfrom=hch@lst.de ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1679320723; 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; bh=9JxuoOXrvBv5R9PUz9wzS/XDpwFhofIR6FWa7Esn6zM=; b=lmuCjUYPdw9IMtVqi3NdSdME+1s4dSlCJDW1vks64botIsW2ANlTtvnbuXsT+BRoceIByf /nUx+uxK60b2kYlBc08ISvvrS2v0nV0VASPzzEtYXDqm8HMM4+ik/YdXQiSIk7uQzoCvQH 21g9zrJwxXOeQBaZQDkB1vdJqS7rZ/I= ARC-Authentication-Results: i=1; imf26.hostedemail.com; dkim=none; dmarc=none; spf=none (imf26.hostedemail.com: domain of hch@lst.de has no SPF policy when checking 213.95.11.211) smtp.mailfrom=hch@lst.de ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1679320723; a=rsa-sha256; cv=none; b=pyedpOba5PY843vLXd6xcO8HBLiaM6l6eS7878yi4iYkBjXYvm+DY4HDuzGRhDGpr7Wiml +BDQC2JJg/S0LDryWSvxY+Ulp7hKwQXdqadpKX4dMdkH52Pi4Vcqb7b8whwTRlOrGFYNIA GH53fzrBiAegQiAnGG8fjGEuM50yX7M= Received: by verein.lst.de (Postfix, from userid 2407) id DC1B868AFE; Mon, 20 Mar 2023 14:58:38 +0100 (CET) Date: Mon, 20 Mar 2023 14:58:38 +0100 From: Christoph Hellwig To: Hugh Dickins Cc: Christoph Hellwig , Andrew Morton , Matthew Wilcox , linux-afs@lists.infradead.org, linux-btrfs@vger.kernel.org, linux-ext4@vger.kernel.org, cluster-devel@redhat.com, linux-mm@kvack.org, linux-xfs@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-nilfs@vger.kernel.org Subject: Re: [PATCH 4/7] shmem: remove shmem_get_partial_folio Message-ID: <20230320135838.GA16060@lst.de> References: <20230307143410.28031-1-hch@lst.de> <20230307143410.28031-5-hch@lst.de> <9d1aaa4-1337-fb81-6f37-74ebc96f9ef@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9d1aaa4-1337-fb81-6f37-74ebc96f9ef@google.com> User-Agent: Mutt/1.5.17 (2007-11-01) X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: 55C86140003 X-Stat-Signature: 9cgznqe6abrae6wq9wqww8f13f5mt9k9 X-Rspam-User: X-HE-Tag: 1679320723-594108 X-HE-Meta: U2FsdGVkX1/jMdRDegyPXUsI2Dx/UR6bWKmSyNEWYHbZjurZx3JsgjLzkI4tIiEhb/Sxl0JYLsKB8OR8zUrrwncwi0rfpAUy+pz8dVwV31F1lpXs1s1H/SSm9jnUZMbzM/02vu/XXjEcnlURi74d1qgLq+SP7Uz+E5xzH6SqA5WPNvJrQ5ZQ0VN5yqykTls+S0czVMvbSphoRpANqZboj9FcHh6q2Eak0J9T4xb0RtzioeNyTC2aqye4R7QHmhtonubER0vGYKp6KZXbN1RrIfaP4tB2nppT9FznmWjX+8zkLXpRBxIcOp7VByVulQO/zRpTKVanQSBkVVZDjWvKgvPAoRqK62MDkQj56MWIHm4GPMLKLdU+9zRkwUKEr2mIfwF8Ygx1YzTlq5i6Gi9Ubu7/tSsZFosV7VVWdNk+4c/5q7MOuFpUZAsCiricBTspvXo51f7PJXjBXE7md3VNQrBcmONMAbAwrz/U7XvV+qS7a7V0OGcAPU4fo0xuhK5rqp4RL4hqbqH8Jpq4yCcMKGIVkTxYJ1kOp9mvmpG4P6s3BqpRg9xtGRN/ahIKCLukytBbyu3jYzfV76vJeA9u40UBwsb949dI9XKsrWTUUdcVnWJTMbGLYkYqY64xllXW0t36i8Cjhdjz3GT/PAVqrz9/z7uxl45+964FnGtaGDExQxBFR+CXks67uxydqG2PtUzw4gdALTDb+CPguJHU73GTnpnmdlGe/vda/C+Wz8qCGHOKgp8bSxbUGeiGp17MyWoweezP/D6ZgFrkkEHHzX1rBWpzrjKRVpYDZx6gvF0pPccmXz19heZdNSyxf6d24C0kEWXnWO3cF+rXVaT4laCsnrjX7KuDG2s74vn6sjdSxdNIft5la4G9/QDJYmZ0D8giyKYtSUUqKfGgmoB+PfHObXjbBr/FC1M9HjxTnddrG5KWvrruob8Lfrf/UZ+IxBe6TsepPQR1Bi9f1Zv ZUH7Ce1p HsiTA3C2IhD/bJ4XBHtz7KdkC9+G6AwWnQ0MZG0Y/zEPfTmPEHDFBXV2HLryQz9BHAE4wOpK9EnW+fmUEZhur4iBwWwstTFnxX8WpMr/8rxwB9GPSW7f9kG0N7w== 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 Sun, Mar 19, 2023 at 10:19:21PM -0700, Hugh Dickins wrote: > I thought this was fine at first, and of course it's good for all the > usual cases; but not for shmem_get_partial_folio()'s awkward cases. > > Two issues with it. > > One, as you highlight above, the possibility of reading more swap > unnecessarily. I do not mind if partial truncation entails reading > a little unnecessary swap; but I don't like the common case of > truncation to 0 to entail that; even less eviction; even less > unmounting, when eviction of all risks reading lots of swap. > The old code behaved well at i_size 0, the new code not so much. True. We could restore that by doing the i_size check for SGP_FIND, though. > Replacing shmem_get_partial_folio() by SGP_FIND was a good direction > to try, but it hasn't worked out. I tried to get SGPs to work right > for it before, when shmem_get_partial_page() was introduced; but I > did not manage to do so. I think we have to go back to how this was. Hmm, would be sad to lose this entirely. One thing I though about but didn't manage to do, is to rework how the SGP_* flags works. Right now they are used as en enum, and we actually do numerical comparisms on them, which is highly confusing. To be it seems like having actual flags that can be combined and have useful names would seem much better. But I did run out patience for finding good names and figuring out what would be granular enough behavior for such flags. e.g. one would be for limiting to i_size, one for allocating new folios if none was found, etc.