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 356FAC10F1A for ; Thu, 9 May 2024 12:55:29 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 904206B0083; Thu, 9 May 2024 08:55:28 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 8B3A26B0085; Thu, 9 May 2024 08:55:28 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 7A1E56B0089; Thu, 9 May 2024 08:55:28 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 55A456B0083 for ; Thu, 9 May 2024 08:55:28 -0400 (EDT) Received: from smtpin12.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 8D170A148F for ; Thu, 9 May 2024 12:55:27 +0000 (UTC) X-FDA: 82098853494.12.85541D9 Received: from mout-p-101.mailbox.org (mout-p-101.mailbox.org [80.241.56.151]) by imf06.hostedemail.com (Postfix) with ESMTP id C4F76180018 for ; Thu, 9 May 2024 12:55:24 +0000 (UTC) Authentication-Results: imf06.hostedemail.com; dkim=pass header.d=pankajraghav.com header.s=MBO0001 header.b=xtVL76wK; dmarc=pass (policy=quarantine) header.from=pankajraghav.com; spf=pass (imf06.hostedemail.com: domain of kernel@pankajraghav.com designates 80.241.56.151 as permitted sender) smtp.mailfrom=kernel@pankajraghav.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1715259325; 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=Dfpr4O1ruwod+MTm7pGPfWogKD4Gt2EPTVtvHr0sOQs=; b=yxuG/xGz7rrAw8JRw30jyO//S1WbmNxBpWGDJvMb8sKWT269l2XZswFqPtFEC41RrhBr26 qPMs2nxr63byey5RGscACY333OkI7qLbnred15ODmWxcIS27cOMEMNc2ZQXXhWMKnByNHl +gUVc5S3uODGa69Sdo8ln72OanZY61U= ARC-Authentication-Results: i=1; imf06.hostedemail.com; dkim=pass header.d=pankajraghav.com header.s=MBO0001 header.b=xtVL76wK; dmarc=pass (policy=quarantine) header.from=pankajraghav.com; spf=pass (imf06.hostedemail.com: domain of kernel@pankajraghav.com designates 80.241.56.151 as permitted sender) smtp.mailfrom=kernel@pankajraghav.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1715259325; a=rsa-sha256; cv=none; b=dZisTL/XD+dkbo7+UkGKqQgJtQd9OdRfj/keZ3gdRLSrfxJlIb46ccQNlos28MR9W2YUKf TyGJM5OYy50MdLdhRzWrBJbO4IpraSayt4cBDVEYbKU6FyCwlJbylAy5qe8PZK1AbqklSg oEAxdfDKB0o3rOqJs4/GBgPgJkO+to4= Received: from smtp202.mailbox.org (smtp202.mailbox.org [IPv6:2001:67c:2050:b231:465::202]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by mout-p-101.mailbox.org (Postfix) with ESMTPS id 4VZsS858jXz9sSD; Thu, 9 May 2024 14:55:20 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pankajraghav.com; s=MBO0001; t=1715259320; h=from:from:reply-to:subject:subject: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=Dfpr4O1ruwod+MTm7pGPfWogKD4Gt2EPTVtvHr0sOQs=; b=xtVL76wKt6rG8+F7KEd/puC+S7PZTXghfnlMFu3YrT77cDpYnNDzGw5jHLGr0NA2FLYjvZ 84XZgst8xi9n7HvHw96PSpsgatVenbaBdLmPcLUSN9qddu4m9JXEXcE0YDl3owJT7GQD40 ENZpttER1BHCfU4k5tDNTPBh2ZufQ8LUguhRhaA0ThPw95B9ZxExViRYb1YLCNXtTDOEve ne3wpNt9JGcTB3A1o8feQV9gj6ba0nTpIdHEO8AqGl/b/yOAztckdz/71iP+M2QmwSL47z j1QB9OujlUyv9iGK6lwnK9AYIXWGHcMi6s2Bn9zbqXBOgP47/SBjrIPnkvHnFw== Date: Thu, 9 May 2024 12:55:14 +0000 From: "Pankaj Raghav (Samsung)" To: Christoph Hellwig Cc: hch@lst.de, willy@infradead.org, mcgrof@kernel.org, akpm@linux-foundation.org, brauner@kernel.org, chandan.babu@oracle.com, david@fromorbit.com, djwong@kernel.org, gost.dev@samsung.com, hare@suse.de, john.g.garry@oracle.com, linux-block@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, linux-xfs@vger.kernel.org, p.raghav@samsung.com, ritesh.list@gmail.com, ziy@nvidia.com Subject: Re: [RFC] iomap: use huge zero folio in iomap_dio_zero Message-ID: <20240509125514.2i3a7yo657frjqwq@quentin> References: <20240503095353.3798063-8-mcgrof@kernel.org> <20240507145811.52987-1-kernel@pankajraghav.com> <20240508113949.pwyeavrc2rrwsxw2@quentin> <20240509123107.hhi3lzjcn5svejvk@quentin> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: C4F76180018 X-Stat-Signature: dhmte749itz4c5afd1z6kk3uzrto4ngg X-Rspam-User: X-HE-Tag: 1715259324-213510 X-HE-Meta: U2FsdGVkX18g5xJglShFMPHDgQa0/t8m7Qnssp1ukv3b2t2YaqdUpDyu0kdKDqFGhOnfROeuNJUel02kiPQufMAyzvPbaoHiSf6OtZRVPDS9H27u3HnR8hiyTv1olfbH21IZvQFm4HvXouHFUdtZoC7Nwc5X7wLGOnMFSc1ejDiFLOuCuZ13mXBJMPO1m4UJK95Lrz2pSqEugldokt2SlUue5q2l7xgpqjFVvZHCJIu7rLd0WJeuSSZ+Zh0UVC1Ca7lr50iaHjoydhGPyZvZunX2Nmj+9IzO349EvRjK807DOFb3QT//84B0ti8Vo8Pns8O2XafrNF3QSEpjgBegtz9eew0XGwN/e4RMHRRrPxErEXHzUljACFGxll0Q4+5j8cBWUZCGMdNPqImllNAnAGd8gjAboDPUVSufE8J5IBJTgStox/ysjPSeINkRScaoVNB1QTbM0+3iIZHD1isEWJQapSDDzU16fnKZWZLDxT0AVcQtUBWoZDrzXGga7wiFWr/McssAWlZUUGp9OncmElM37Gk+S7zosaomy10JQanqDqSpPmUwNat5VeTtlutb8Jfbp9Ipj6sUXxZQ/UvXSlnmXDrZfnMKudHP9c4yUVFjHtVzjgu2Cku8s8Hjs3FSiadsFvQWkDHk8EVzmGXIrPV2JdbBGBF+baTuTwRvM49YTmde59B+P7ke3+zh6Pl369x+g4XRKn3SKBi1M6xFPYdJcOQFtt6rihcURACwvj1dljrHe2UMR4WtM0T2YlfyB/wNygwY9r6ke+cR+5hAaTbmKdsI2Vl3Mu2mGKgepzIcT2KhN7E+I1ld04E2g4oDQawo2JTIOG/LCJRGWb6WAAzhEfvWq9b1tjFN5veVirGHZQbsxddbpt9Ibt+GecMtVLXkaf4bmU4RMO8z0X0du8Gbipg3YhacbCs9FkqoksVFQixYF5k6E2ZLdBXsiuB8YKimdsw3bL0KAX8PEEF auHl9QHU gtlAHXVajWzccG+5BsYvkSUg09qL2kT6ikza9cK+7NzuQpI2SRR/xIPc18kMlOy6HURtI5rp6449cQxYyqgJzsFQ44jlDETxIu3x+qR8qUFZ8WVMca2BqAOJ2OoTD5ueyJvxpcrmCaPmzH+AFg/44NOFEuK7xp6RrXdLacO0lY7tA1rPqg+rZ/6XwDK6ZbQdoXCJOS5KFRG++a/BEyO0fuetrj8AulDL0xIyKh6XgkzHv2xr6kzdstO8Cw0Hy5QQkXfQs1YOpAXS49CaO3ULQ+R1V7ox27/7g4rv3/YjUzXBspNGFsyOMTIaBquiiqH0ff02nwf5h1DN9GPQ= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000945, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On Thu, May 09, 2024 at 05:46:55AM -0700, Christoph Hellwig wrote: > On Thu, May 09, 2024 at 12:31:07PM +0000, Pankaj Raghav (Samsung) wrote: > > > Well, that's why I suggest doing it at mount time. Asking for it deep > > > down in the write code is certainly going to be a bit problematic. > > > > Makes sense. But failing to mount because we can't get a huge zero folio > > seems wrong as we still can't guarantee it even at mount time. > > > > With the current infrastructure I don't see anyway of geting a huge zero > > folio that is guaranteed so that we don't need any fallback. > > You export get_huge_zero_page, put_huge_zero_page (they might need a > rename and kerneldoc for the final version) and huge_zero_folio or a > wrapper to get it, and then call get_huge_zero_page from mount, static bool get_huge_zero_page(void) { struct folio *zero_folio; retry: if (likely(atomic_inc_not_zero(&huge_zero_refcount))) return true; zero_folio = folio_alloc((GFP_TRANSHUGE | __GFP_ZERO) & ~__GFP_MOVABLE, HPAGE_PMD_ORDER); if (!zero_folio) { We might still fail here during mount. My question is: do we also fail the mount if folio_alloc fails? count_vm_event(THP_ZERO_PAGE_ALLOC_FAILED); return false; } ... > from unmount and just use huge_zero_folio which is guaranteed to > exist once get_huge_zero_page succeeded. > -- Pankaj Raghav