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 A6595C25B10 for ; Thu, 9 May 2024 12:47:08 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 335286B0083; Thu, 9 May 2024 08:47:08 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 2BEAD6B0085; Thu, 9 May 2024 08:47:08 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 15FC86B0089; Thu, 9 May 2024 08:47:08 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id EB6706B0083 for ; Thu, 9 May 2024 08:47:07 -0400 (EDT) Received: from smtpin18.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 60278810DC for ; Thu, 9 May 2024 12:47:07 +0000 (UTC) X-FDA: 82098832494.18.2C7DBC3 Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) by imf08.hostedemail.com (Postfix) with ESMTP id A6235160014 for ; Thu, 9 May 2024 12:47:05 +0000 (UTC) Authentication-Results: imf08.hostedemail.com; dkim=pass header.d=infradead.org header.s=bombadil.20210309 header.b=jDbif7ib; spf=none (imf08.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; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1715258825; 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=N2ymIQ4SsJGpIWSTK0c3WPAw6ggOxtbl/S0hlzGrq8E=; b=K4H+U5ywJYO+Mdi50AKrehxKgCmFptYJRVEk3467RwMF+c5LvVreAav6dKK/p20aMlQCyk ElOv07lHwu2qXsi5JD+DiSY0hvwvF8QxtaOPRVdXaHjqjQgSCfJrNMqPu/fTxg8z6ZPt65 T6U9+XOyt4Xv29qgi4BDqV9/a63yU/4= ARC-Authentication-Results: i=1; imf08.hostedemail.com; dkim=pass header.d=infradead.org header.s=bombadil.20210309 header.b=jDbif7ib; spf=none (imf08.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; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1715258825; a=rsa-sha256; cv=none; b=sn/gkG/YcW/4ks5CPI3/Cfy/SrxsoJJhSv5EoyD6/pHq0PFmHNUxpvo5a3Syh6fHrVXI1N 9lxjOxZNMmkE/g7mH9d0NZCBnpraRkXEM002B2PDQ0aL+8LoZ8g4Zn+4hga19Qc0vi7iBR 1HcqOMIoLyBvSfixRC07DOE8U+eOezg= 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=N2ymIQ4SsJGpIWSTK0c3WPAw6ggOxtbl/S0hlzGrq8E=; b=jDbif7ibDbh5aLoH4hTssJX4rL qhd2lu2gCkirS1lT+kNSrVuNhnHEtxAl7cYimVQs/+shVV3dnIKSWPpI5WZ2SX+kN9mKNeh6Of6c8 ZutFJ8uyS1Xh/JGHtDQJLoZ0+nAav598JCmxorINaWdpGcAMoMnnpv19TY0+Ksa3HGhujefpH2wqW Dp3cXY1XvOfA/e33L7CieFhhr/HGalWwAb/nJ2JKhoLfnHhxPGttFSJxf7KFJ1wtaj72SKzIfHus/ XjKoTkmzmL5bFWviJtXAjNNip7zD6cOyK4+UdOjS7uC47EmRSQLa2maK+dLRaDFHf7qzRYhFaCoIL im5iyCcQ==; Received: from hch by bombadil.infradead.org with local (Exim 4.97.1 #2 (Red Hat Linux)) id 1s53Al-00000001TaS-1N6z; Thu, 09 May 2024 12:46:55 +0000 Date: Thu, 9 May 2024 05:46:55 -0700 From: Christoph Hellwig To: "Pankaj Raghav (Samsung)" Cc: Christoph Hellwig , 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: 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: <20240509123107.hhi3lzjcn5svejvk@quentin> X-SRS-Rewrite: SMTP reverse-path rewritten from by bombadil.infradead.org. See http://www.infradead.org/rpr.html X-Rspamd-Queue-Id: A6235160014 X-Rspam-User: X-Rspamd-Server: rspam04 X-Stat-Signature: nggayhaakwcdm9xhq83ba4yin4y49zjg X-HE-Tag: 1715258825-755730 X-HE-Meta: U2FsdGVkX19WWhHJoEE2T0tW8wJKuUuSC3SddFE9vPvaY2CQFyKFnqeAgCLgWcLGBoRaBJqFCmgv5sCn8tYKcImBkFq8KCXzRJP1WI78H1C69gcaEBPpVZ6J/GEMkzJVu/MeIS87PZIu/qzgafdoIKLPnE+Cns+y8YtysflxWhZ0/syV4ol2f2kAMH4yAtIQWVO8qBMK6U9oyUOv0huBJVlB56PXt6dkGI6r8T9pbdNbaB4NSF7jaWU8bG/+Hukg+IjGWDuwE4CToXE7b6lqBxWHWEgSub/Zf8jH6YJdTCg84S4BGyw+rkjTiWfJ1j4GZ001ZUGY1vgaD0fJBTSsgNMD3mt4rlTZcV7eta96lA5qA/JD8d9ixs8rG7pKkpIwqI29nQzu3G0HEUqj9Qgc+bMO718Kr8XQuGuQwP14m+FRJeOzD68jl4oG80WKI/3lgHiZ1Fc+tUhTFIT5yGLwBL4CQ6EY3eS2GCQri0jK5rAOnYXRRfQ1pVamEA7SjzlZBp/OFqgicHIuAhGBEF+qjRl6XkKFB/UHOzUuQ+fT668vIah2mBeYbn/6QndMCTGUQbJ2a4WJOxMSlv3igdPs9F//l/WG11oyuXV3AbVy8MUQ9D8msexBYSPBtWpM4H24GzMF7mAnv/FfoXFQ3UFu41kTcgDcuDnfh78dEAykK7rBWjb2lMQsAl7JiH0H6JtLSwzmVhCZnWdK4yiznNlIXuyzUl4sC2gDZ1DaqmW1tHdpJBI47t0P2R1ZSoDIYsQgcUbfquhj4IHAKxHvLn22xQRKnHbBzHRXb0csRWr7DtkMosb838BLeB6GnoU9yMpKB2ztLRjN4i5QPMbi7QSb0W+NN19/eWcoEeqt9hsw5J+NHmbF/uP2PNQZOyO5C8EAJwuXir3cdbi98Dc5sq+VoYbmJ1w+ifD0iHUUn6h1+/JsNhRWHm3kwmDsNozKDcHtcrfbxxxo+58kPj+HIt1 6UYttzil J7fQld9okjASUhIP4QaHQ1pLnVG5aydjAzSSVC0S8PEiziamB49i0xXNC1ZgRVhZvRL1eXDX+66A91fA8NEXbIJcZ81R37lyblilmuRHed7kJ5TSdqV4H+Jc7OftRNkipZrQ4ioMyLoyMq0Ye02VUShvgfgrZbcq2r0kTBmmbIAuWmiyWjR7Pgrj1uBSdV1nRrmc71mJnKYvQ0poPIxHmRLojOU0T0C/ga0z6hFqgEvbNVu0SSCc+dHiR3aJG44ekzBr0OCx72zBGmEUdiQInECXCNqGKoy49/MCgfyiUPo9PogSLLACikRaPEa7qjoGCVG+/aJff5S0WNJDl0rpMVD2+F81yihYjKHovxoRm9i/ea06PLV/TCSm3YW/7pgCnhHKI+j65RzxZ0VvFjnn/WgUc5dG8YGKEFijOxJAB8J8qo3LGQQpkqr8rFUAxV+63h2MJKmymaHqzekNQd1H48G6KQ+cd3Mu0y8V0R5Oyt7M68SDngdFbUTr3xQYhmNTq4IX3 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 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, from unmount and just use huge_zero_folio which is guaranteed to exist once get_huge_zero_page succeeded.