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 7A3CCC25B5F for ; Wed, 8 May 2024 11:42:47 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 130F56B00C7; Wed, 8 May 2024 07:42:47 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 0E1C26B00C8; Wed, 8 May 2024 07:42:47 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id F12546B00C9; Wed, 8 May 2024 07:42:46 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id D3C026B00C7 for ; Wed, 8 May 2024 07:42:46 -0400 (EDT) Received: from smtpin05.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 73E21810E0 for ; Wed, 8 May 2024 11:42:46 +0000 (UTC) X-FDA: 82095041532.05.002CCDA Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) by imf09.hostedemail.com (Postfix) with ESMTP id D100014001F for ; Wed, 8 May 2024 11:42:44 +0000 (UTC) Authentication-Results: imf09.hostedemail.com; dkim=pass header.d=infradead.org header.s=bombadil.20210309 header.b=HHbd7SaA; spf=none (imf09.hostedemail.com: domain of BATV+51ef0b7171324ca53c39+7563+infradead.org+hch@bombadil.srs.infradead.org has no SPF policy when checking 198.137.202.133) smtp.mailfrom=BATV+51ef0b7171324ca53c39+7563+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=1715168564; 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=BYab8gfnw71vLMZVwC4umL8NG4B6+6Id6Hpb6wOPWjk=; b=BCcktUQlhWHAXzcozs9M0G+joMS8XUMBUtLiC7hBSxwchSqyb9JJx8c+7eWKAeTbVciJOh KOTP+lfsTrj52JznukKwLEvUfLehj9KCOLqQw1hDjtLcC9trKAEBaNJ6ceyleJTjdT/SdY mvgEKBXLjUiPAPBxGzQzlOZxaeqymM8= ARC-Authentication-Results: i=1; imf09.hostedemail.com; dkim=pass header.d=infradead.org header.s=bombadil.20210309 header.b=HHbd7SaA; spf=none (imf09.hostedemail.com: domain of BATV+51ef0b7171324ca53c39+7563+infradead.org+hch@bombadil.srs.infradead.org has no SPF policy when checking 198.137.202.133) smtp.mailfrom=BATV+51ef0b7171324ca53c39+7563+infradead.org+hch@bombadil.srs.infradead.org; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1715168564; a=rsa-sha256; cv=none; b=Ips9vaISpEWIpb16wm1eMXrWpqYohDf5ahrs6olKorqqUcDWfLOiYN6G+2tqPkACsjU0gj mDMFLK+7qGk32uOjsPT8MCzLTu80Zs9MAN3CzmObvSgdWwmaXOe6KeNsxgQ8R51/Eodp8Z 3j6RJmqPUyDRM4u6u77ax3m+dYu8jTo= 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=BYab8gfnw71vLMZVwC4umL8NG4B6+6Id6Hpb6wOPWjk=; b=HHbd7SaAADfmXktCJOTkLr+66V AkDUd67kmMYelDBlifdDtViqKcxM6NNa0WZuLHAGmLtUB+2WRucyP3b3r63VEauAIsTtmUI1N2g9d j/3ko+aQVQ4UwWEPWLQUGNCQzozSxiX0vC/RoZhoRbmQhWV80UNlKa+Gp3pwQzZNtGQXdlqNMXVF5 WYcZRiWIc8T3T7I9H6H8VVTMQMNGEvb+Cf+WamZ70/ZuvvFYk2+Y4c0MhrS3Go1p3PGrlEZmhO4TP ktr9UWzu0LOpDFypvammstDWUzo7p4kSO4X2da1/RQuNqhy46pk1Ro30IaOBxfEh7BkBett3mVBIc eeramhCg==; Received: from hch by bombadil.infradead.org with local (Exim 4.97.1 #2 (Red Hat Linux)) id 1s4fgy-0000000FJ7p-0WDT; Wed, 08 May 2024 11:42:36 +0000 Date: Wed, 8 May 2024 04:42:36 -0700 From: Christoph Hellwig To: Ritesh Harjani 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, 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, ziy@nvidia.com Subject: Re: [RFC] iomap: use huge zero folio in iomap_dio_zero Message-ID: References: <87edado4an.fsf@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87edado4an.fsf@gmail.com> X-SRS-Rewrite: SMTP reverse-path rewritten from by bombadil.infradead.org. See http://www.infradead.org/rpr.html X-Rspam-User: X-Rspamd-Queue-Id: D100014001F X-Rspamd-Server: rspam06 X-Stat-Signature: p71rtni11918eh4kb4g6ww6xh4wk7gtb X-HE-Tag: 1715168564-29526 X-HE-Meta: U2FsdGVkX1/fwbAVOLETqLD2/9hJ+Q/sABSkNTD152eml4/TX8P/NQWGXej8B3BYPePk/eH9cx9Q10wDapGUi9PkQw7qpO0/lV/aoFGY0k4dPZzoy7JNkPs5cCM+XVX4k1r2cfc81PbbFuF0PCQz+rICTJ9v4PmFvQfYqkp06+b4hjMizJd2Sw7ZQmFtER+CrhxDQxGUYzLJm7WE4g5TT+k2LsNUJWaseSdId4T546Ik1hmIqcEIgox4XOni+61XqIHmeZiKt0veB2EfMTYL10Z6F53R2cC9l8vx0QSN2VejoDsY8aKiJPTGGFzPZKXhVUscDRWn9MuPMA2cmNFGKqBs3Ol6Uo7KGi+LH88sqN1iVnqbvgHutlqELVfDhDtou1fe8BQLeSEktDgOYL7fSrARV0pV9h+aFtIdyUStzEkab0iBxAEAyYy8hpn0j1qnscG6WYSUOdMgjq05dU9IA9lkyAcnWh5FHWbI2jFpTwW9+HtGwtw1mDbxAJITkHJTPUJMNyLoVO0uGl+wf31q1s85Otg8jT2P7QVsCDUDKzBbL8+6deTcaKS52cYIPWKhfGk25Jdv/qvce4X6CbP2IQivojo4fTHXu2jrAzbhwjQQsfRoxBNX3Y7OqAacQyWRB/9RK+/db+/qgQJB1FW8UVym9GKQBCsjh4nr+Auk04AKZnsVuhtFfUh+asJ/3+0xqJL8nAMuUr9jLOrA9DQkT3A66GhWGjXiWrESTRBzY8HxizDn0+ghz4Rw8hhf1KhSbCqU8+8aEjpbGrqIrudW8et4Z4pZDVEpPsmf4BF7+bwWcJq8xxIQg4dbmo+bw6q7FwdUvwM+2vTPSWRYk/95PLT+7ITHanZxTcbRZppZpsHF164xpmTecJarAlmnjjE7yMjhzyBlOUBFAWEK1d6HWpTgrUTge2gjj/jAtbArrlCEaQMWTEKPEn0jtlSdJOMqEJ89xGOEJAbjOJKdyCr NAA9PVVs Rz+L6WG0DC6OHg5AbTprhUjrZjXjpghg5aGz9utT5NuJ5kVbGEkWIWM8u8JGg/EWuEqcMtgesyTbCmZUxuqiTDCE14m/v6JEXUpp3S9hT0k2rwQymo3AK4PSPOaPGvmR4ChouM/BiJHKkbVDpTpwYR7KGe0d78LC0zNBaMly8i2sp4I9+JiYGpSQdOGp9hT31hfddGihV7oP7FGLzf28aC7sful2Nq5avLphlArVGuwOBEVC/MLO3Nl9p1Aw/pxiSp4rYU/gAAv5p0Jj8GrbWsiZwsJD/SOFdKF7eUjaXRylw1gWzyKDuzRMCAbXP0E0m8NRFFsqqxEZJHFOnKNvmkhpRowBM/8Ij2T6CQwJeB7hlXNkntRihnI8YnhcjUyMZyKIgCjT1QCQkDzIRRqTrJzUQgQxSbH2CexHXwiHevqfUYF5rIZ/7HZBX580yOYquEgnY0CmslMnYyf6w9l8GpyX52HKHIEq2Vkz8y2qDqgFwFw6gnHBlQV4f0zLzzrZfDmR8RyexxBtc4waATes3fvRAhcj6sDyEr4yEdgZLE6E55Q5GE5A+Uxpyta+pJpwUh0Od 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 Wed, May 08, 2024 at 12:08:56AM +0530, Ritesh Harjani wrote: > Christoph Hellwig writes: > > > On Tue, May 07, 2024 at 04:58:12PM +0200, Pankaj Raghav (Samsung) wrote: > >> + if (len > PAGE_SIZE) { > >> + folio = mm_get_huge_zero_folio(current->mm); > > > > I don't think the mm_struct based interfaces work well here, as I/O > > completions don't come in through the same mm. You'll want to use > > But right now iomap_dio_zero() is only called from the submission > context right i.e. iomap_dio_bio_iter(). Could you please explain the > dependency with the completion context to have same mm_struct here? mm_get_huge_zero_folio ties the huge folio reference to the mm_struct. So when the process that kicked this off exists you lose the reference to it. Which doesn't make sense, we need it as long as the file system is mounted. > Even so, should we not check whether allocation of hugepage is of any > value or not depending upon how large the length or (blocksize in case of > mount time) really is. > i.e. say if the len for zeroing is just 2 times the PAGE_SIZE, then it > doesn't really make sense to allocate a 2MB hugepage and sometimes 16MB > hugepage on some archs (like Power with hash mmu). I'd kinda expect we'll just need it for so many other reasons that I wouldn't worry. > The hugepage allocation can still fail during mount time (if we mount > late when the system memory is already fragmented). So we might still > need a fallback to ZERO_PAGE(0), right? Memory fragmentation should not prevent the allocation due to compaction. And if we're really badly out of memory 2MB isn't going to make the difference vs all the other memory used by an XFS file system.