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 7424FC10F1A for ; Thu, 9 May 2024 15:05:43 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id D09036B0093; Thu, 9 May 2024 11:05:42 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id CB97A6B0095; Thu, 9 May 2024 11:05:42 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B808E6B0096; Thu, 9 May 2024 11:05:42 -0400 (EDT) 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 9B7B96B0093 for ; Thu, 9 May 2024 11:05:42 -0400 (EDT) Received: from smtpin02.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 442EE161607 for ; Thu, 9 May 2024 15:05:42 +0000 (UTC) X-FDA: 82099181724.02.44F02FE Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) by imf04.hostedemail.com (Postfix) with ESMTP id EFF3040007 for ; Thu, 9 May 2024 15:05:38 +0000 (UTC) Authentication-Results: imf04.hostedemail.com; dkim=pass header.d=infradead.org header.s=bombadil.20210309 header.b=p7jh5Wrw; dmarc=none; spf=none (imf04.hostedemail.com: domain of BATV+16439c8c750d17eda2cb+7564+infradead.org+hch@bombadil.srs.infradead.org has no SPF policy when checking 198.137.202.133) smtp.mailfrom=BATV+16439c8c750d17eda2cb+7564+infradead.org+hch@bombadil.srs.infradead.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1715267140; 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=NTxQ6b9gJV4qPcNNolosfP527XGyNxAyMqN2wlfwLmo=; b=NnHsKcgVewklVrPTgSf3FfAOK2p/VctPTlfOkVsohKXdC3N7zAgziFbqdMtGiVysOGYM+5 uEGay9gSSStR2HH6pU/Vv4hiGIvFv87G1ITXLOWfbfIAsNhfWBg6HfqVKajSLQtLYRjjmJ 1bQRFUrct/LFLLUXTkv5BUPE95dZLBs= ARC-Authentication-Results: i=1; imf04.hostedemail.com; dkim=pass header.d=infradead.org header.s=bombadil.20210309 header.b=p7jh5Wrw; dmarc=none; spf=none (imf04.hostedemail.com: domain of BATV+16439c8c750d17eda2cb+7564+infradead.org+hch@bombadil.srs.infradead.org has no SPF policy when checking 198.137.202.133) smtp.mailfrom=BATV+16439c8c750d17eda2cb+7564+infradead.org+hch@bombadil.srs.infradead.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1715267140; a=rsa-sha256; cv=none; b=gJH9QBZR4xgHrhscVesBrwJtPjem+K9EcXVUT0Lp1ZEGLVzQd/C5F3Rgrgi1PR5c+hB3vp 4zcSe4KBxp+U40LjdMzhgyvUtPNX5odckwx6QpadR+But/wcLNF8US7Dm/gE1IJQO5ywB9 AkQslMhrfYC/EXy77F9ndC5lGcK8iUU= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=bombadil.20210309; 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=NTxQ6b9gJV4qPcNNolosfP527XGyNxAyMqN2wlfwLmo=; b=p7jh5Wrw8y3OsGiGmfbt4hL1jK taC66FQQcRrAfbtFdUUVPhAx8vcQAFvszEAqNmrMe+KvnqhwT5WkDsfd4z3E7fxZz1VGuWckP66nr SNd9Wf1LvVmE6yVcHASC2PpdPNuw98Kg6YhvlNSBgxhvSjCTMdCBpH4kqEY/Tw7x8wpKqKRfaoXRS FyvwPWYLQycN5drHGFb5cMC+Fwc0HWo+et5hQ5h3GRZ3vMXLuzzV4nIaBtBo5Q1ram383ZNoOmdYH ZvB8dT5gr9zx0A1ckhFczLA4LDJ6TfqroFB4a0Qflggf8SBoG0NubsSj8Q+SyVzNRF4NblXEZy7K7 8jnMko/Q==; Received: from hch by bombadil.infradead.org with local (Exim 4.97.1 #2 (Red Hat Linux)) id 1s55Km-00000001ogW-0Vwe; Thu, 09 May 2024 15:05:24 +0000 Date: Thu, 9 May 2024 08:05:24 -0700 From: Christoph Hellwig To: "Darrick J. Wong" Cc: Christoph Hellwig , "Pankaj Raghav (Samsung)" , hch@lst.de, willy@infradead.org, mcgrof@kernel.org, akpm@linux-foundation.org, brauner@kernel.org, chandan.babu@oracle.com, david@fromorbit.com, 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: References: <20240503095353.3798063-8-mcgrof@kernel.org> <20240507145811.52987-1-kernel@pankajraghav.com> <20240508113949.pwyeavrc2rrwsxw2@quentin> <20240509123107.hhi3lzjcn5svejvk@quentin> <20240509125514.2i3a7yo657frjqwq@quentin> <20240509143250.GF360919@frogsfrogsfrogs> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20240509143250.GF360919@frogsfrogsfrogs> X-SRS-Rewrite: SMTP reverse-path rewritten from by bombadil.infradead.org. See http://www.infradead.org/rpr.html X-Stat-Signature: bdhm5puf6i635cjwuy6hy47r7ypnbegw X-Rspamd-Queue-Id: EFF3040007 X-Rspam-User: X-Rspamd-Server: rspam12 X-HE-Tag: 1715267138-742193 X-HE-Meta: U2FsdGVkX1+ZD3/dGyjTXjvE7Sco7jfWRQXF+Yx1XtL/lnMWOMnPZ2H8+grWC6kETo3H3CMItKJYwWkAg5l3lcMtvpT7tP8WTrVA/eFOqjCRuPoZjjndlIUhPPWKKxDBI42QE5JTwiInjVuIcik1pl7jC6r/pcOL50GMZ7Nmdn6CyWKBn69mUwtFXz2SFUyKlqbXygnWb+1LExjJ1eVcPgCdz7cI+TQs+x2urVsAcdl8AhDIEf0lAkWOwxVDeD4hJv48s3CWAxeBfbd+HRHYdobwnHKDK1Rjqx8WipZYlTI/ERtTltX3EJLEU6wi/UBE6ucU9v5yhSYOgLNZYB+pAoYUT5URflsV/O7B+Ge4AbF+ZhHlWtaw+fFJdSulo+ybSm7Xn5bfC8Xu5ziV/KuIuU9Z41v46HtN/fw3sKTjamvjoQinOh4TYdAowjC9iEqk7IngnSjPg6RjCrWJD7drki9xj6zV3UrItuWi9zCnk20+hsAeNEGRijkOAaYOeVMuyzoF6fOGTXBZfqQSONmsoJtbYAjQYmU8ICH86y5grWDoojMgP8V4cfcZ8jUO9hsonP/FyE3VmiGcQh3Pyts5cVwKdNIBgc/L/o/9nUVI4PaOxRt7N7F3ythM3coSPICeQKBb8AxqjxEvIKZivFp495WlOL97l3aLbRsxQW/plk9VFcaqkABFNspoX8b7twbz5xzpSJZ8iJ5864xwQ1P/mO19nbyrVpppPzwKILIUiPg1zIyt93OyFsGFAPyi3a6jmPeuDr/J1/rff6krF3K7ECHCYHWUXCIb5PAxdqA26MeZiSSDpEDrbA5g8YnzZczZ6L1JbBDzKCur1sAYbsWrI0Ud/hKbpaHayJqPs64rXkdIAvXbDhHTUzhGFfz6p2+zF0NalE1CCg/uBwNo6NtR/nj6Gl09Hw/CW2Q0wS6PLWnkNbbTbtp/eo/jI3gTo5XpIfgWc+Tj3oGvuIkGcHR h/m8pMqc 31Dwo8MofKexnQIa+res4G/tyE9GKBQLW6Q5OJ1EbajvjYSU/Mdrst3iLqsBZ6EXXmGF8UiYWnoXsND84svrGRJBLKMxlF5IXCeb/inEGbLKREI+zP+0IdzcDPnC49Ne8RFb4ah6vHPDAfV5ZdYs56luGTbDGOwumSocB3QJoVQhQhz7YmxqzDNasBqVR8YClYoPczqYYkSBTNc8qzMwwp/zsFRgrkqjmDal23ovOjq7lszVBiAbcX1GDx+lNSqwIMVlOOTvampOz7DKZ4XWynmwMADe6zYIjZk4J1KokKxtcxefl1bWkkGT6JHDe0rdOQiw2V1BM0rZz7IHcmtCR0ryY+kZeCfaQ0cWSnS9ilHu55JfxZJ+HVNclwxAwuc9AU7R09rd/yxiXLI4mjOxhWr1Sd6UkIqPyXYsqVB3tnhyxxF8sK2GukibnhOWh8K4VPJ7+RCygsdCP0l051eK+YryL86pk+Ojw0NfIGkfN1VYQZx0/JhUSu34I4dGY6bJnVWsb 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: List-Subscribe: List-Unsubscribe: On Thu, May 09, 2024 at 07:32:50AM -0700, Darrick J. Wong wrote: > On Thu, May 09, 2024 at 05:58:23AM -0700, Christoph Hellwig wrote: > > On Thu, May 09, 2024 at 12:55:14PM +0000, Pankaj Raghav (Samsung) wrote: > > > We might still fail here during mount. My question is: do we also fail > > > the mount if folio_alloc fails? > > > > Yes. Like any other allocation that fails at mount time. > > How hard is it to fallback to regular zero-page if you can't allocate > the zero-hugepage? We'd need the bio allocation and bio_add_page loop. Not the end of the world, but also a bit annoying. If we do that we might as well just do it unconditionally. > I think most sysadmins would rather mount with > reduced zeroing performance than get an ENOMEM. If you don't have 2MB free for the zero huge folio, are you going to do useful things with your large block size XFS file system which only makes sense for giant storage sizes?