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 7FF27C64EC4 for ; Thu, 16 Feb 2023 11:56:18 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 8F1BC6B0073; Thu, 16 Feb 2023 06:56:17 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 8A1966B0074; Thu, 16 Feb 2023 06:56:17 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 790E96B0078; Thu, 16 Feb 2023 06:56:17 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 684FD6B0073 for ; Thu, 16 Feb 2023 06:56:17 -0500 (EST) Received: from smtpin07.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 1FE30A0BC2 for ; Thu, 16 Feb 2023 11:56:17 +0000 (UTC) X-FDA: 80473001994.07.7F081DC Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.220.29]) by imf14.hostedemail.com (Postfix) with ESMTP id E9D07100010 for ; Thu, 16 Feb 2023 11:56:13 +0000 (UTC) Authentication-Results: imf14.hostedemail.com; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b=m4oUtuDw; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b=eh8edWAr; spf=pass (imf14.hostedemail.com: domain of jack@suse.cz designates 195.135.220.29 as permitted sender) smtp.mailfrom=jack@suse.cz; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1676548574; a=rsa-sha256; cv=none; b=wU3rhnJcVqhfEXDksNClVdBmsaZiQQNQx9oFvt+O0nIixWTtnJ8MKSsF7KVd3JT50+8Vge 0H9hcGbiS/8pKTDRqvJFspImlhEo9pDKObE1DGN4f4IFF1upOO5vcQKHqe7rdcTHYBpbI5 Fssw7a02JWtl0urvPi1U4ffRg+8iDgU= ARC-Authentication-Results: i=1; imf14.hostedemail.com; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b=m4oUtuDw; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b=eh8edWAr; spf=pass (imf14.hostedemail.com: domain of jack@suse.cz designates 195.135.220.29 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=1676548574; 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=ULeOsmeRWlu2iwQvL7JPfZ/4t11CdcUZPAn+Hh+0Z9Q=; b=brJSQd4ZgtkPPMUhekmTp/KRbgyxoUx1PZWtmCXm+/E0dbI3K3MG7DZIonlLhuPO+yAStp 4NVF2EWZix6LdcXx1XKzmJjYpaizRmrJ9ehoViP64VmDxv/Q2bqKaM1qIjuaC5gAqJ5lOm 3leKoW0Cn5vc8QXGEDEUzjRewZBMWCY= 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-out2.suse.de (Postfix) with ESMTPS id 595FA1FE07; Thu, 16 Feb 2023 11:56:12 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_rsa; t=1676548572; 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=ULeOsmeRWlu2iwQvL7JPfZ/4t11CdcUZPAn+Hh+0Z9Q=; b=m4oUtuDwrM7EElnSEku7NyUtsy0MA2HvUdwMQDdT9wxpp2CfILhHqTYAR7GuphyhcfFzDf DiraWxNJrSXL+Q5IWysB+sx5mefAiyK6myr5en9DhVAiY2y4jSt3DkY3BT4tNPshuFRYhV UAGTqxEMGr59vi6gbLkwfy0SwCEwBXc= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_ed25519; t=1676548572; 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=ULeOsmeRWlu2iwQvL7JPfZ/4t11CdcUZPAn+Hh+0Z9Q=; b=eh8edWArsKrgZ72r9dQcSP6FX7aEzxbJlgzyPvRWJAi+K/kzirphimpjeRb9upVhSPR26B xAmBB0b9a2H7SbAg== 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 48175131FD; Thu, 16 Feb 2023 11:56:12 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id miOTEdwZ7mMEMwAAMHmgww (envelope-from ); Thu, 16 Feb 2023 11:56:12 +0000 Received: by quack3.suse.cz (Postfix, from userid 1000) id B24AAA06E1; Thu, 16 Feb 2023 12:56:11 +0100 (CET) Date: Thu, 16 Feb 2023 12:56:11 +0100 From: Jan Kara To: John Hubbard Cc: Jan Kara , Christoph Hellwig , Matthew Wilcox , linux-fsdevel@vger.kernel.org, linux-block@vger.kernel.org, linux-mm@kvack.org, David Howells , David Hildenbrand Subject: Re: [PATCH 1/5] mm: Do not reclaim private data from pinned page Message-ID: <20230216115611.lauxr34lqigrc73n@quack3> References: <20230209121046.25360-1-jack@suse.cz> <20230209123206.3548-1-jack@suse.cz> <20230210112954.3yzlyi4hjgci36yn@quack3> <20230214130629.hcnvwpgqzhc3ulgg@quack3> <406c3480-ab59-5263-b7bf-d47df0f6267c@nvidia.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <406c3480-ab59-5263-b7bf-d47df0f6267c@nvidia.com> X-Rspam-User: X-Rspamd-Queue-Id: E9D07100010 X-Rspamd-Server: rspam01 X-Stat-Signature: czggdi56gu7kn61bs9c6dn86jrnbjo4o X-HE-Tag: 1676548573-533284 X-HE-Meta: U2FsdGVkX18YUug7OA5tGTfXRfx2AukuZKKpyfHHHVuoCmd/A3agnpUG+SGEQYrXq+dEMorzTviy3G12bhxye0kvJ89Jg76YLASjOQCt9aklHTjjrai0QgF+QUj8F/ZLjjF91sC5EZTbzEwAO0ol9Z1pDYKlj8jytEmEwOR53xIkNbzonGjaUDvMc1VpJ7QxawMtGwPriTaFLzcnbZ94+kx3AE9M8zNpo5tihvHpEv1KZZj4hYMCyOEzICtluzk9iKRzkEfY1vdPH3ZquRkGseWRe8qihg6pWyWu3U+zVfSQpDS+79VQbwux21lwxbcB77zfuOMD03s9zxMFZ2Skdp5LBF1UVLBg+CcLIyz2tMolkiNKxCWXKEV+msaIXXRrb7E2drv3+HKUzugyXz8f0s7sPQg9bzN/cPR8cxoaW3o7WGOtZOFRmS5LLJSUYr3wF9m7HYS3SN4eykXYeBSvjx/VYOQK2kv7vv/bE8iqLWm0vSkoMXRMj+RYUlLuEjEmTuJP+asTABk9w5PvbrZmAleJ51ul0Z3Jh+GUxSx6076uHeJ+OiU6qBXHSJN8pw/6MRLs3UAOnkcxUTqA5tG9jkRyPRT8dA1jchUL6KsxCZHXqe99AN21qZIgXPr16w14841pWWtu3y23oE2Vmm5XF9fC12pYQLVYjFtWJhcDtmixrAA8ZlocPOPPw6Pw+xYR0efdtB8/DL0Ji443RNr69KTBeV/dpM+jONaGwxQA1jVjyvBmXBpjcvPU84j3psnS2SB6WMMd3mT/tXXDA67JmhlaG+Drs2UTkIzt2oRU18/CCk6NmCInyuGmrr4oCqytCvCvxT4hhzxyBvWRHOUESaaxzvednjgW3R5Oqc58nxCFIDDjrG+eRVfJ4ffM72UZpX0ersEkMXv2VC0TqSgz/zRAOHRO/SAMBgTPqUQjRQ0Klmz2/EOXB5FL06JFI6Cw3bWcHKmjH7gXRDNU3qH QIBuWCwd EBfPmCc3mQ7qHPDP9yknvyxARnmf8Hps3eUbMB1qZJHPAYvnOwK/skenKCdA44uxiB29QTirIn3EysaELvyVJnnuhpgO9IYv/PV/9pONJPsOcfKY/FUKkLoVkn6SS3ONUZ4T+mCVM4jVECO8z2JZ1KwBHUIgSLbHVOjDhyG59scChe3W2emWJFj2WkJ7os1LJtRpWzRqvOd1PrBPHGMD2MxqJVLM/YyphStPHJZcyTRmED531EEHtOQrJuFUAqi27t/RoRT5qWIis8RQ= 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 Tue 14-02-23 13:40:17, John Hubbard wrote: > On 2/14/23 05:06, Jan Kara wrote: > > On Mon 13-02-23 01:55:04, Christoph Hellwig wrote: > >> I think we need to distinguish between short- and long terms pins. > >> For short term pins like direct I/O it doesn't make sense to take them > >> off the lru, or to do any other special action. Writeback will simplify > >> have to wait for the short term pin. > >> > >> Long-term pins absolutely would make sense to be taken off the LRU list. > > > > Yeah, I agree distinguishing these two would be nice as we could treat them > > differently then. The trouble is a bit with always-crowded struct page. But > > now it occurred to me that if we are going to take these long-term pinned > > pages out from the LRU, we could overload the space for LRU pointers with > > the counter (which is what I think John originally did). So yes, possibly > > we could track separately long-term and short-term pins. John, what do you > > think? Maybe time to revive your patches from 2018 in a bit different form? > > ;) > > > > Oh wow, I really love this idea. We kept running into problems because > long- and short-term pins were mixed up together (except during > creation), and this, at long last, separates them. Very nice. I'd almost > forgotten about the 2018 page.lru adventures, too. ha :) > > One objection might be that pinning is now going to be taking a lot of > space in struct page / folio, but I think it's warranted, based on the > long-standing, difficult problems that it would solve. Well, it doesn't need to consume more space in the struct page than it already does currently AFAICS. We could just mark the folio as unevictable and make sure folio_evictable() returns false for such pages. Then we should be safe to use space of lru pointers for whatever we need. > We could even leave most of these patches, and David Howells' patches, > intact, by using an approach similar to the mm_users and mm_count > technique: maintain a long-term pin count in one of the folio->lru > fields, and any non-zero count there creates a single count in > folio->_pincount. Oh, you mean that the first longterm pin would take one short-term pin? Yes, that should be possible but I'm not sure that would be a huge win. I can imagine users can care about distinguishing these states: 1) unpinned 2) has any pin 3) has only short term pins Now distinguishing between 1 and 2+3 would still be done by folio_maybe_dma_pinned(). Your change will allow us to not look at lru pointers in folio_maybe_dma_pinned() so that's some simplification and perhaps performance optimization (potentially is can save us a need to pull in another cacheline but mostly _refcount and lru will be in the same cacheline anyway) so maybe it's worth it in the end. Honza -- Jan Kara SUSE Labs, CR