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 83FBBC04FFE for ; Fri, 17 May 2024 13:30:59 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id D98E76B0085; Fri, 17 May 2024 09:30:58 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id D4A0D6B0088; Fri, 17 May 2024 09:30:58 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C107F6B0089; Fri, 17 May 2024 09:30:58 -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 9F3206B0085 for ; Fri, 17 May 2024 09:30:58 -0400 (EDT) Received: from smtpin20.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 260A8120175 for ; Fri, 17 May 2024 13:30:58 +0000 (UTC) X-FDA: 82127973396.20.6C53A13 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf29.hostedemail.com (Postfix) with ESMTP id 02BB612001E for ; Fri, 17 May 2024 13:30:54 +0000 (UTC) Authentication-Results: imf29.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=mDZbhB0B; spf=none (imf29.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1715952655; 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=xp/PqiG39gfb+fpKlsrloVFa0KFhPJTa9GfWfq4DY7g=; b=4t4CMUjUFFsj3/DScQDCjv8wbvcryEn5NXpljMa6ebSlVZcI/cKls4//sJoEJbUTwTT7/n qACV0Lb8I9KL+XZsjWljvCmqZKxdJxH6NGa0CuoZPvQAqZ7vCY3wIGO61auBeNrUoA8uqD Yky0mCw9mxWxiAP/jVyXtbCYyPkCZt0= ARC-Authentication-Results: i=1; imf29.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=mDZbhB0B; spf=none (imf29.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1715952655; a=rsa-sha256; cv=none; b=N4xAyFeCKVX8rzLViDaZ2UvJRWJEf4CJwYNyCd5vEVAid0dArCqKryWkpSqMTkgQuAJBnv NsO9TK/PsGXTWmteLMHetbriHz7rW+nasTMbv64T+5lDw9inTpPwZOC7qTAHehTaqKg3EU HuuhStflyLY+fumJHit1wZvs4A7jdhU= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; 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=xp/PqiG39gfb+fpKlsrloVFa0KFhPJTa9GfWfq4DY7g=; b=mDZbhB0Bo4bbgFpo9pkLp89Vj/ wQhzCtsKtWw/04XAp921BFJxBDJY6bKoMlhnaWs/54a/1u1WvxzalD9IdR96CnYYZulpOTk6HWhEB EfnYBHEk4GWrbYshJIU+8S/L+sPZbDV9m7DT0xMEzDeqI3v13dwbYqJHyda0BW5fTVwUAt74I2LRv Yw3g7+uck/GtcjPYkivUx3OA2yVDFL584Z+TD7Le/+0jiQU/tJkb4heNIKtfoMqVUX2ZU4XNJUOhV PsovbgyNjpACoJlqCKmgn77Dehb5jY1xIvWyHk5cTn+Uy31F5OxzkgAEEEjQwamqrAPHTtSSdZyTr vJwYQbqg==; Received: from willy by casper.infradead.org with local (Exim 4.97.1 #2 (Red Hat Linux)) id 1s7xfW-0000000Czht-1Hei; Fri, 17 May 2024 13:30:42 +0000 Date: Fri, 17 May 2024 14:30:42 +0100 From: Matthew Wilcox To: Hannes Reinecke Cc: "Pankaj Raghav (Samsung)" , david@fromorbit.com, djwong@kernel.org, hch@lst.de, Keith Busch , mcgrof@kernel.org, akpm@linux-foundation.org, brauner@kernel.org, chandan.babu@oracle.com, gost.dev@samsung.com, 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> <20240515155943.2uaa23nvddmgtkul@quentin> <20240516150206.d64eezbj3waieef5@quentin> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspam-User: X-Rspamd-Server: rspam09 X-Rspamd-Queue-Id: 02BB612001E X-Stat-Signature: jyfuuqru9rzibz88bwqsck4te5kpu9ap X-HE-Tag: 1715952654-985052 X-HE-Meta: U2FsdGVkX1/+Q81jF8glO6E0ylAzh+aIrWFIdm/3A7bhq0ouCTvDRKdAzPLKIAwfbU8H1O6IsT9KOHU18LDZIcI+RiCHhC7Cd2LrqhT9/lNeTYwIDzYeQb0nzdYFnO8lvPLldrtr//M9ERrAwi9Ua7xpRNNrK+B8BmU2pEChSQebbdsc/U3OX4b/CBUgyqbkJbzAR3CN2aLCo/J5YGzEi4lNM93iWWeCyPa3J2M/MIf+Jt2t4ClMGBRMwGMfe6htlZ+2HemMlNUS56ahPC1x/CP4/XlWxIwIH8NukaAX0ghtge23MGznVTW8E6ZS0OscH+HZYrGeutwWq4Cqtp3iaS/9mA4Tx9nE/1Y9DCRImT5XOuog9RO+kB6olnA280t3KQ/0oU9al1o8LwtF4e89A+wVjOthuuna8EgWNHNHJh///Wif5IqxFwKpT+dJ/7Ar0L3BFCCqpris7uvFqGt3rYKwEwyTvfIpXEkp+6Rfyf3tjB2X6txLcHQJ+k4cEZM3O4KVQNO3T+bVKuPCfAUhqHGZ7FmxprnnUERPxQCvSJZs0Whtwy/9O9/rPydAnrzq5RaLvEaGViOlTXbo6q6xmH18e7zNc4Rg6w/2K9z+/4DbuR2o1XAcrcGveF6NyZGzLzpofG5ugHzFyogqs8nrY701P07lcwdFhJplaoaTngQ2pTuO+yOaCvlFsKl/A3TI5kxv5VUATGUxkbQI8qKfMEEiUx3TPJ2E7JxE9xl5Hn8iwIqUyr0N5KfLg4Oa6UUNRSA78KJ1eSoFUXR5hEZhCB26vJ0NS1YmpeCNbwS9G/xjahtLi5iDDPzrDV2r4Zn+6m7tJn/oKOfQVHqoWxfX2Qmx7bE7WVMBg56cs9mYq746DLzVFZ1DJBoUmXB8+vNo6elVjXlA80/bY6KT794725K0VROoS6fygO3vaa4QmUQ7Js/9Q9Jmo63S3zJ+KGPS8EeDT2wb4pJvrlcWn3D LPzCjF19 +uw5m6iqLA5ExXLXB98fsoVztEyQbFWYx98lEin/cdPdtKh8pyocnONxkVIcUGSGYxL5YpGDXZf6lTZj2U/a5B48K3J4hqaajm3VdyOXbjTpaEZd7VaNsE0thBLcrHHX8bSDvNhBw+1y5NHGwK8FUIsssvposPOchMdj0DpikEMtP0p4DA0TutrP2RDIgJatkyArLJcI6O+9dPl1NzZnjS2TJbJgZv3WEAyJQsz0wRWu5K7Z3P49UD5ni5yu9DSbdWU7n 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 Fri, May 17, 2024 at 02:36:29PM +0200, Hannes Reinecke wrote: > > +#define ZERO_FSB_SIZE (65536) > > +#define ZERO_FSB_ORDER (get_order(ZERO_FSB_SIZE)) > > +extern struct page *zero_fs_block; > > + > > /* > > * char_dev.c > > */ > But why? > We already have a perfectly fine hugepage zero page in huge_memory.c. > Shouldn't we rather export that one and use it? > (Actually I have some patches for doing so...) But we don't necessarily. We only have it if do_huge_pmd_anonymous_page() satisfies: if (!(vmf->flags & FAULT_FLAG_WRITE) && !mm_forbids_zeropage(vma->vm_mm) && transparent_hugepage_use_zero_page()) { ie we've taken a page fault on a PMD hole in a VMA, that VMA permits PMD mappings to exist, the page fault was for read, the forbids-huge-zeropage isn't set for this vma, and using the hugetlb zero page isn't forbidden. I'd like to see stats for how much the PMD-zero-page is actually used, because I suspect it's not really used very much.