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 023C6C369CE for ; Thu, 26 Sep 2024 12:16:51 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 7F69E6B0092; Thu, 26 Sep 2024 08:16:51 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 7A6CC6B0093; Thu, 26 Sep 2024 08:16:51 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 66E3A6B0095; Thu, 26 Sep 2024 08:16:51 -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 47DE96B0092 for ; Thu, 26 Sep 2024 08:16:51 -0400 (EDT) Received: from smtpin08.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 069341A176D for ; Thu, 26 Sep 2024 12:16:51 +0000 (UTC) X-FDA: 82606788222.08.66A2F5D Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf13.hostedemail.com (Postfix) with ESMTP id 9CE1020014 for ; Thu, 26 Sep 2024 12:16:47 +0000 (UTC) Authentication-Results: imf13.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=VvkAnkYF; spf=none (imf13.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=1727352888; 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=3JXNnfCuu1FGFtKqoh7Vb8SASSIWNgmcdOP5HIJ3eY8=; b=33gYFyEyaOqbuOLUZECN7AjHljEYFwCqbroKz4/UMcaBE6fJDuCcw9RL3knn43VefO9Onc Xb0ch3AJTt/huXkKvlPgnd/sekro0eNyj6O7ExhkRWZ3idIUNfStME4Qu0LAEKgSqa6nhT fPH5kkfTBiWwAObvkui9Gtri6FSyjm4= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1727352888; a=rsa-sha256; cv=none; b=cClPBBJlr1MDeXJsIYk+BTTMmjxaFZFijVfBPZEroDleAm5cHuHmsXZglZ0klc3wvIj5Ob XDqZxit3pPnmQEI29JBi0hx+yKg7Uvu+ql/gUhpnU4rwIXdCBTWqGO+ArXDKjPM1nTwnCp 7d8g/UiV9FMJ4YDMWKcEuklbiKNrjVY= ARC-Authentication-Results: i=1; imf13.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=VvkAnkYF; spf=none (imf13.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org; dmarc=none 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=3JXNnfCuu1FGFtKqoh7Vb8SASSIWNgmcdOP5HIJ3eY8=; b=VvkAnkYFethV6nNbSDLPYYVpx8 1AY0iZNwy7XaY3WK3e+EQps9A3CbSfTitVOqnPsYqkVm9MzNAh9Zo21t9TjXBNSfxBCPr1AK97HcR 3BWDTzI1UuDeSdYSR2bw/i0Nxu6vJIYDJGyCgqB/m+H2B75Anjc9Xs8kXIrKx0OIgkns85AM4tJAk 2FfiOuwqjoPl9N9dNREJjzB78tLKG4qCmmo/iAZDBHuVpv/tFXm6aUkuqog909ESWColhkiScCMzQ NsQA1BANqYJTA+DC6+KIBOT15z6h6gfH7qdAbCaMDG3iIXdj2P4foV6IqjS67Xg/FA9x1P8LWnuUx /zzqCgWA==; Received: from willy by casper.infradead.org with local (Exim 4.98 #2 (Red Hat Linux)) id 1stnQ9-00000006aqg-1qAG; Thu, 26 Sep 2024 12:16:33 +0000 Date: Thu, 26 Sep 2024 13:16:33 +0100 From: Matthew Wilcox To: Baolin Wang Cc: akpm@linux-foundation.org, hughd@google.com, david@redhat.com, wangkefeng.wang@huawei.com, 21cnbao@gmail.com, ryan.roberts@arm.com, ioworker0@gmail.com, da.gomez@samsung.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [RFC PATCH v2 1/2] mm: shmem: add large folio support to the write and fallocate paths Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspam-User: X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: 9CE1020014 X-Stat-Signature: u48ahygazmxpxxkg85utygrag13rndgg X-HE-Tag: 1727353007-902478 X-HE-Meta: U2FsdGVkX1++Si/iC/nqP+3Za6SoW06qQVNktNDTih1ENvf+0Ydh5jtSFr9pVH3BY/WmnE3/dEXrJrToSzAhE8XiM/zeBnQH3oY/ehWJKC1jjA1niiD13Fz1s8eo+rcHNSYzrGVTWgv07Tlg/q6bH8xl/vDiZXyzKpHhanPRaBXCPs9cWTsEP0ZS2DjgFrfYD0dw5ULm+lMOTOonpPTCcE7ll1zuURU1btDiIPzEqejXBBLbz4j+Yy4OTk5CKCQcpa5uUafAlXLrUUbtP7a2WSqzHoF1CsZFu+UYecpu7UjqHt0m9wG44GJ5wNiQB94FNFS6HcwK+ICr2hielPwzMbTbZfTlAWt0ka0lGA/dUhaj+M9yRBRXEh8SCNcAXEwn5tg+MmVSAHE9XNjL1QgcDHS6epXE/iY/crKsWDckt2xDZgHzahfUF3ZVsY9zOidzLq6V+CNaGx1oVX9kktOblPPonYkCoZsKaWoyGWk9AtkNV1oJKZw5nUWoXb33dVNPL+X77iecfIOmhkaXhfKLc0Zufwc7gk/18ICsk21mHJSNb5Pj9jmZG6C0i1ninNLYRmoRKmSLdC40yYHdXCquMOV72LmOFMo4cj/8yX+fjeWmTAaHdTsfdY8fJ+ut/ncIDHa8zsulO8/cqZfIqgGw0WkySHEsryK6tFT7pkboGuXJxKseBP22ffUa0c6k24LAxNeZVSz2cXxDs7S/9vsplkVHyjomUdTCW1wOlaagyDh5MKlqIwWsmebwT/bqADjxIR3redoLg0CFv0RuFoOl5nR6ZMhCZskPz0KABu2jLe+kalSV4LnYtK3+K14yC1M27t0wT4koefVYJV67AvOxP6O0zKd8KV2lW3wth6DlCFSImVonauly7vodcFOPL/9eASlM2VrX3dq4h5zqFAFBz4pzvc42PwxAYKXV5DhilGmILGb/af0Y23P9vSNL4gAjJb7nEisKkDBlSXVtHf3 mK+MYSmF vFyeJdurSJlRanzn3pNEuvdhrd1IGmz7qWgTv+71xLRT/dLb7y00zQc5l+DM+4aLhsy7V2G9UEQa+w+zNZkKQfMqaHw+mnATR56meATpDo5uNz/ubUmsDM3BU+FmOJN7zhR6qM85rS/zTll0Ld3k3UGD/h31PjtJXLKDIyaIoKupM3shdB5NJxt4yv5g2camaTy+rKfgbSr8QEMDpyrW4Ke2s6865q4ZAwgYb10Td2Ov32Wk= 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, Sep 26, 2024 at 04:27:26PM +0800, Baolin Wang wrote: > +static inline unsigned int > +shmem_mapping_size_order(struct address_space *mapping, pgoff_t index, size_t size) > +{ > + unsigned int order = get_order(max_t(size_t, size, PAGE_SIZE)); Why introduce the max_t() call here? Did nobody read the documentation or implementation for get_order() before writing this patch? Besides, get_order() is wrong (at least relative to other filesystems). get_order() rounds up instead of down, so what should we do for a write() of size 512 * 1024 + 1 byte? Other filesystems allocate an order-8 folio plus an order-0 folio. This code would have us allocate an order-9 folio. I think that's a bad idea.