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 5DAC8C636D3 for ; Fri, 10 Feb 2023 11:30:00 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 97700280007; Fri, 10 Feb 2023 06:29:59 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 927B7280003; Fri, 10 Feb 2023 06:29:59 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 7EE9B280007; Fri, 10 Feb 2023 06:29:59 -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 6D4B6280003 for ; Fri, 10 Feb 2023 06:29:59 -0500 (EST) Received: from smtpin04.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 23D5A1408D4 for ; Fri, 10 Feb 2023 11:29:59 +0000 (UTC) X-FDA: 80451162918.04.93D94F1 Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.220.28]) by imf05.hostedemail.com (Postfix) with ESMTP id 26E7F10001B for ; Fri, 10 Feb 2023 11:29:55 +0000 (UTC) Authentication-Results: imf05.hostedemail.com; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b=iLExC8SQ; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b=7PJxxC6z; spf=pass (imf05.hostedemail.com: domain of jack@suse.cz designates 195.135.220.28 as permitted sender) smtp.mailfrom=jack@suse.cz; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1676028596; a=rsa-sha256; cv=none; b=QhGFWW3lNWERinMLysLDUd3CMv0qiQtgIPI9KDv7RAjimvaQY4jEvP6FMeSrCatL06qCfK halcgjp+iL9/jZiHSXtpGyU3MNsFAk+6sDIspUpH8ZKydexsmCGqhmGaYlLw9F7zkEPiGl GR3vnz+GibZJljBu6JTd3c+5ljUTwZI= ARC-Authentication-Results: i=1; imf05.hostedemail.com; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b=iLExC8SQ; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b=7PJxxC6z; spf=pass (imf05.hostedemail.com: domain of jack@suse.cz designates 195.135.220.28 as permitted sender) smtp.mailfrom=jack@suse.cz; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1676028596; 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=lFG9hUKx5RRv1kRzAuMhtm3Isu2cMLDvawPdmQnL++E=; b=dwlSaGPlfFtqtlIe40NJrAMHKusMJ1eVrBTsd+fI/piqDay+lM5Yl46uThF6vtbxJTLRQE E5jXbJegNJhbd+EyJEKnm1vIIKTCPhWNpdXFcnh+h3FyU8i0hxRqOpY/QBgt0Qr8zHoEA5 eWMR+bK9XbR05F4l3I8bZOkIYvVwtNI= 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-out1.suse.de (Postfix) with ESMTPS id CE56A3FB47; Fri, 10 Feb 2023 11:29:54 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_rsa; t=1676028594; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=lFG9hUKx5RRv1kRzAuMhtm3Isu2cMLDvawPdmQnL++E=; b=iLExC8SQhldLpRfnwmoj45BeA10gdTreaMJNx5DkhzCdq67WT0ELnmNQSnb4Jpn9Ym/bA7 bEq8VFUcuITuRDnlS8094fQEFAqCnJDS9vKZ9dfoHPFf6iHAF2gTO+4XDqGNDxObuvy/fs QVyEfN5XKyiAY2E1oqwsd+esGVjdqak= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_ed25519; t=1676028594; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=lFG9hUKx5RRv1kRzAuMhtm3Isu2cMLDvawPdmQnL++E=; b=7PJxxC6zDK7A7R9L/dIFeqQwgCw2IKxRhmWZYd1WjAlizRCwq+fO7HPAvYeEaijjV/pe/l vAFSQbPgAT6J/SDw== 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 BE5EE1325E; Fri, 10 Feb 2023 11:29:54 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id UaF1LrIq5mPIagAAMHmgww (envelope-from ); Fri, 10 Feb 2023 11:29:54 +0000 Received: by quack3.suse.cz (Postfix, from userid 1000) id 3B18AA06D8; Fri, 10 Feb 2023 12:29:54 +0100 (CET) Date: Fri, 10 Feb 2023 12:29:54 +0100 From: Jan Kara To: Matthew Wilcox Cc: Jan Kara , linux-fsdevel@vger.kernel.org, linux-block@vger.kernel.org, linux-mm@kvack.org, John Hubbard , David Howells , David Hildenbrand Subject: Re: [PATCH 1/5] mm: Do not reclaim private data from pinned page Message-ID: <20230210112954.3yzlyi4hjgci36yn@quack3> References: <20230209121046.25360-1-jack@suse.cz> <20230209123206.3548-1-jack@suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspam-User: X-Rspamd-Queue-Id: 26E7F10001B X-Rspamd-Server: rspam01 X-Stat-Signature: 7i3zk83qcs3oozfn6da94rmzazg94w5i X-HE-Tag: 1676028595-752366 X-HE-Meta: U2FsdGVkX1/o//pazXFhhPYs+reAIPy7JPv57FtGOqI1CWbT4ZkHgiOIB6jm9OUpid6aVpEWAwuJ66sR6OcyTszKQLE/1WZv3DqKYmsDN6Dx/L1vRnBpZYmhvhlpyWT+i+giqmY4WWqng7nEv5KqfTEN6HRDV3ELplj5twLP4eaEyp6c7EB6JCes4+bwASeYl+7Cg00zckpF9OQjHhb01hqExdEHimiS8BrFQcKkvbYWFvuSV33pyqz4kl9Vw+xuZzmiGbSJ/S/qelOPCtIlnImGL7nLSwC6/JGUvdA7QTgrOpXe94PqNQl6yx27BUQpYTabOr6DFySCqCkQrcMXDd6Kg8jUEgXS7GXayme4spTxAYffVg0/T5MC07S9CdB4Y+NrPECAC/IG3H+JMglUgpLLbt/Wn0iBOnFTKEs3VnQTE9KbeIJXQO+dzqTgDcTRtLXcup8vDVJxeZN1S5hVXdh2q73Iz+uoJHBphu7egmHgH8la1iLnCeZS77OCBtSCkljj4C16aAYDLPNhCcIZXJT5KVcdd61Wb2VmSm71KzGABEl3W4D8WYOh9lfEeztUhXJF0c77sBtr7teEs6076Pz9ODFmcUUg+7NPMLJhiSKgszr33/BDe6o/kC2kVdG16H1N0j4zn5VRZbv9vcKKglanfqUHDa1SNIVG71ARybD7uhmjIqBIpxS8xY6ssxc9Y8hb96rVvStvlQd+Q/rZZYtW9/3dWeWCFR4XjG677OpT607qKlArOgXKKI+Dm+A9NqCmcfXAJEyGnJGpEFqDvaazayB0v1hf8kMT9B9F2MPT8dZNNey8Dt5Wq5Kg/1SJuJjRsjcWk538/inPQE59NWfmbbT6q1D+0CSTY800NxWVVJ5cMmRmcmwVKDMXIF7PJ8woVG9YHfgZctV4MQgEAtNqLpRG/pLqIG46LEAZj3qY1bMsHB8q0Av9OBWkr9td2pFEh2DXLk48pPa8U8g 2svT+4Qs cchuoY3ymnbE7YdhOZKAccy0sAV/CrVKw4gcn/uBuGWnODOltUrq+Uqn0V0hS1PzNzlCVLVQftSNZ4bga+HPpaDMEGEnnE1zx7WSm3eWUE/sQzkilm+6A8WrDU01CFdjD6oBboFLXEV6o/dMiX0lAo4jrzq6OTSEr3mB5Z8k+eHxpwSVZiklQ9h5xn2JAdwH/cPV3wkdecOtnEKRUemJVVPjzmOTCouwQHrG/IU2bYh1rtOXUUYeavEnfcZXEDRaJ+hksaMzXKmXcuR7uuU/oxxryow8Fe1kSg6rpDU+9uRBWtdw68XwZ3I83SKSaLD5vcgimpJVZ7kdU1abTYrLRBl/ZDzM7thJtiziq 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 Thu 09-02-23 16:17:47, Matthew Wilcox wrote: > On Thu, Feb 09, 2023 at 01:31:53PM +0100, Jan Kara wrote: > > If the page is pinned, there's no point in trying to reclaim it. > > Furthermore if the page is from the page cache we don't want to reclaim > > fs-private data from the page because the pinning process may be writing > > to the page at any time and reclaiming fs private info on a dirty page > > can upset the filesystem (see link below). > > > > Link: https://lore.kernel.org/linux-mm/20180103100430.GE4911@quack2.suse.cz > > OK, but now I'm confused. I've been told before that the reason we > can't take pinned pages off the LRU list is that they need to be written > back periodically for ... reasons. But now the pages are going to be > skipped if they're found on the LRU list, so why is this better than > taking them off the LRU list? You are mixing things together a bit :). Yes, we do need to writeback pinned pages from time to time - for data integrity purposes like fsync(2). This has nothing to do with taking the pinned page out of LRU. It would be actually nice to be able to take pinned pages out of the LRU and functionally that would make sense but as I've mentioned in my reply to you [1], the problem here is the performance. I've now dug out the discussion from 2018 where John actually tried to take pinned pages out of the LRU [2] and the result was 20% IOPS degradation on his NVME drive because of the cost of taking the LRU lock. I'm not even speaking how costly that would get on any heavily parallel direct IO workload on some high-iops device... Honza [1] https://lore.kernel.org/all/20230124102931.g7e33syuhfo7s36h@quack3 [2] https://lore.kernel.org/all/f5ad7210-05e0-3dc4-02df-01ce5346e198@nvidia.com -- Jan Kara SUSE Labs, CR