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 ABCCBC4167B for ; Sun, 3 Dec 2023 23:12:16 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 989966B0288; Sun, 3 Dec 2023 18:12:15 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 912896B028A; Sun, 3 Dec 2023 18:12:15 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 7B33A6B028C; Sun, 3 Dec 2023 18:12:15 -0500 (EST) 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 5B72D6B0288 for ; Sun, 3 Dec 2023 18:12:15 -0500 (EST) Received: from smtpin10.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 2C76A1C0410 for ; Sun, 3 Dec 2023 23:12:15 +0000 (UTC) X-FDA: 81527057430.10.AB2A66C Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf09.hostedemail.com (Postfix) with ESMTP id 561F8140013 for ; Sun, 3 Dec 2023 23:12:13 +0000 (UTC) Authentication-Results: imf09.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b="In21qF2/"; dmarc=none; spf=none (imf09.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1701645133; 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=y3LBuPegj961tX4hMsjT+qqXDDKi0s85tHCAlRoUSZ8=; b=aja3Rc98JcxKpF1Ab+JLaHFcJ6NRJQo4in+k16KK3511RGDywiqKF8MXExOQNbKeVX4LfF xGdXuPtrL5qW3y2vdyIb6eYvKfl7QFCi1csj3efppJc8znNpCtlsdaU2cMLYMLUElpUrlp 5Q3j1ZFR/0PbzKIkSKf5BmmPkSZiX9c= ARC-Authentication-Results: i=1; imf09.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b="In21qF2/"; dmarc=none; spf=none (imf09.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1701645133; a=rsa-sha256; cv=none; b=5VurbF1rWfoMpTFDoYKgzTLqMoP0iUK2TMdueMN/GbpuDFOUuH8Xi99YnVj9w8qJAC+uFJ UdUyCulxwzKGDEdl1uqsjHJ2IoZFsOINzJCgFFkqCV+UdWfpAPJYfT9vUh9X2rnWL5lGic CsOenRa/3PxIMZG1+UQmAy8hvbLnOAQ= 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=y3LBuPegj961tX4hMsjT+qqXDDKi0s85tHCAlRoUSZ8=; b=In21qF2/1tHy6lNkThOWluMJdj gM0yIwWGvsmhVbkh4DSaibR6bs3lvUfTyf/PRaxAvb6XNGljHbXv2e3EMECQ4NwQNPat8cpanB1+S XVHjhDLLnHEQ/+lY3MKJT+RlRmO+JUxd9x1HN+KWAhUqJ4tU2JHRoNLh7FOFhkWR+jee6LHyy7mSJ Q+lqN8YM+TSnTD5rI1QFCcH7+j62M4GuPUrbt1UguzMCtPs3IM6a5469jsOgd5aauHxuMrrOrEHh+ 9YSCq37Nz43N7gKJSTEep4NK60Og717b3kOfoJ3747A/F+4Ra/6La9jR3XU3INrSuO6NqsFscgEft tOx+RTyA==; Received: from willy by casper.infradead.org with local (Exim 4.94.2 #2 (Red Hat Linux)) id 1r9vd4-00089S-UN; Sun, 03 Dec 2023 23:12:02 +0000 Date: Sun, 3 Dec 2023 23:12:02 +0000 From: Matthew Wilcox To: Viacheslav Dubeyko Cc: Linux FS Devel , linux-mm@kvack.org, Hugh Dickins , "Kirill A. Shutemov" Subject: Re: Issue with 8K folio size in __filemap_get_folio() Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 561F8140013 X-Rspam-User: X-Rspamd-Server: rspam05 X-Stat-Signature: 7mxx8ii55958do6wdu8mi68fcj43az8o X-HE-Tag: 1701645133-842717 X-HE-Meta: U2FsdGVkX18Hl4j3LE8DuWEEVRl+n5H+R78BFqd5bM8xPO8U/W3EJn+96Kn/tpcfYy25evStdYzEm56fYMsp0dJfKBCunArr9MjZe89nvowuH/mBx6ls1k+asQ8EDUe6IBI+bkMBdNRr7b0n+PnU+CqaksUfXTr3BeSBvdKHqu79rud5OwiH5DvO+WahjCNfdprZql78fkMZu9CZbeIoS5De6QNzDPF4wWxEh0lJRktNfcM842nQ6sCOLUIDSdYTePbXvmu9nvrcBE4SCyFMxW8Vax+9t7sCx7tVS+6yxSt3fXQZxTYAI9qAzku3lmc8mjYNkmZ0Dn0nva+nohwm0opCnwI05RKf86/CbgbGyposVl7JPPA52eQX2U+E+zMqmJO6kna2Si6SkzMISgFfeCDvVjWdtWL4XrouT7gcxrX3Go8mHrNyqMuuwnCHm/gg3rDgUPaYWXgbshedhCbruDxgugiC87aPKaKyJewVwlFfCFZWhiW4vU2VOxvvnHWvxb/1xRLN2QLlfb5Mo/H9aOB0JWWn03PwhdrObruZb2BaWzpBqaBPNc4r+iVZO2o4PIjxBl4p+dI4/zBWcu+W59CvxqMUSjGx0pW3/nsMG/OTGCzmNwSjRvpJkZLJWE2Had4SxcnC7u/2iZHT1mAoE8LUEnnr0jL7Pm1zA/k8Aw8M5twTPXCmsIDxbFNPzTNV6bLiS/dom0coc2zU4hbYwQ3InadjOy/LeOUr9lZaBJJS+7+gvkFW+vdrYtTv7MSb4M7/BypZvelA1AsZgyjkUA5CjNxdV3dlcIcWx3qe81jyKrnoWmAVM9xynifXfq4X8vgA0UpjY2DuXX0igy1QSLTG29Eg7Zfd1855MKOTUyHHO2FCeioB7UJJgJBeAz29guqA6LeteqjWs3P7zwUeYLnMhm8OxxOnLQWEOcsgdsQV+BgxGD8HG5vyETKDG0KUCreQVBDVcth58UE48iF gOz0MS6n mVETeilamC1M3LldlsksBsN1ZmCZj25xdPNE0nFDxK0ca8X0V5q09Un4RvKrBzMUD5j9jXTM5tRYjBWSku32HExA0uHo0kNYFcQh5V7lCKgakm1cd4M/kG8O5gOQvm+RCxakaw8Ytz9BoPLtDf+qemde3eXitk0embdxFO0xmQbHCXqsck86jCzfxaQ== 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 Sun, Dec 03, 2023 at 09:27:57PM +0000, Matthew Wilcox wrote: > I was talking with Darrick on Friday and he convinced me that this is > something we're going to need to fix sooner rather than later for the > benefit of devices with block size 8kB. So it's definitely on my todo > list, but I haven't investigated in any detail yet. OK, here's my initial analysis of just not putting order-1 folios on the deferred split list. folio->_deferred_list is only used in mm/huge_memory.c, which makes this a nice simple analysis. - folio_prep_large_rmappable() initialises the list_head. No problem, just don't do that for order-1 folios. - split_huge_page_to_list() will remove the folio from the split queue. No problem, just don't do that. - folio_undo_large_rmappable() removes it from the list if it's on the list. Again, no problem, don't do that for order-1 folios. - deferred_split_scan() walks the list, it won't find any order-1 folios. - deferred_split_folio() will add the folio to the list. Returning here will avoid adding the folio to the list. But what consequences will that have? Ah. There's only one caller of deferred_split_folio() and it's in page_remove_rmap() ... and it's only called for anon folios anyway. So it looks like we can support order-1 folios in the page cache without any change in behaviour since file-backed folios were never added to the deferred split list. Now, is this the right direction? Is it a bug that we never called deferred_split_folio() for pagecache folios? I would defer to Hugh or Kirill on this. Ccs added.