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 bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 8FE2DD0E6D9 for ; Mon, 21 Oct 2024 09:57:10 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:List-Subscribe:List-Help :List-Post:List-Archive:List-Unsubscribe:List-Id:Content-Transfer-Encoding: Content-Type:In-Reply-To:From:References:Cc:To:Subject:MIME-Version:Date: Message-ID:Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=cjr8LPBvhlfkxQdtTVULD8NZhhrbrZYfw2sRTnp3fxI=; b=H6p5jRBFG2I+z3Rl0/ipvWe2d7 ZvrI2D3r5dma3OEUIAVQbUwGC9zgZR4SvzWA7/vfMYxNawyvPn9xPjPBRR1kHTEYlQAg28BxonvvX d8otR0mDfojHPqjIF0BGsqkycSGJvR4rqVuiNilPKsozeBlaGoX5nr8wKRACydAlEpkVlE5V3R9Jr PETKwNn3jybo01DAg/GHEXBMxntxfffc8LbP+YqJUG5lXARcKrT+6XQIObg1PB1MHOtltmlYNAEAD DrbdUHoR/aS1ifMcw94av3IOOzJ8hDXKnZfuPUWkFbMvhIaEyvL1+F1Jzv+DvUNfl48s7j+M5uI3u NQ/4gfRg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.98 #2 (Red Hat Linux)) id 1t2p9i-00000006mdn-2ib3; Mon, 21 Oct 2024 09:56:54 +0000 Received: from foss.arm.com ([217.140.110.172]) by bombadil.infradead.org with esmtp (Exim 4.98 #2 (Red Hat Linux)) id 1t2p8D-00000006mOV-3bmq for linux-arm-kernel@lists.infradead.org; Mon, 21 Oct 2024 09:55:23 +0000 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id C2BF4DA7; Mon, 21 Oct 2024 02:55:50 -0700 (PDT) Received: from [10.57.87.148] (unknown [10.57.87.148]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 2C1DC3F73B; Mon, 21 Oct 2024 02:55:18 -0700 (PDT) Message-ID: <745cb0c5-35ce-4879-9d98-52816f3241df@arm.com> Date: Mon, 21 Oct 2024 10:55:16 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [External] : Re: [RFC PATCH v1 00/57] Boot-time page size selection for arm64 Content-Language: en-GB To: Joseph Salisbury , David Hildenbrand , Andrew Morton , Anshuman Khandual , Ard Biesheuvel , Catalin Marinas , Greg Marsden , Ivan Ivanov , Kalesh Singh , Marc Zyngier , Mark Rutland , Matthias Brugger , Miroslav Benes , Will Deacon Cc: linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org References: <20241014105514.3206191-1-ryan.roberts@arm.com> <915e2f0c-f603-4617-8429-da4dacc862c4@redhat.com> <3f096ba0-b6f0-4db7-9d65-ba0550eb98b1@redhat.com> From: Ryan Roberts In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20241021_025522_011248_BF72EE67 X-CRM114-Status: GOOD ( 24.39 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On 18/10/2024 21:06, Joseph Salisbury wrote: > > > > On 10/18/24 15:27, David Hildenbrand wrote: >> >>>>> Hi Ryan, >>>>> >>>>> First off, this is excellent work!  Your cover page was very detailed >>>>> and made the patch set easier to understand. Thanks! >>>>> >>>>> Some questions/comments: >>>>> >>>>> Once a kernel is booted with a certain page size, could there be issues >>>>> if it is booted later with a different page size?  How about if this is >>>>> done frequently? >>>> >>>> I think that is the reason why you are only given the option in RHEL >>>> to select the kernel (4K vs. 64K) to use at install time. >>>> >>>> Software can easily use a different data format for persistance based >>>> on the base page size. I would suspect DBs might be the usual suspects. >>>> >>>> One example is swap space I think, where the base page size used when >>>> formatting the device is used, and it cannot be used with a different >>>> page size unless reformatting it. >>>> >>>> So ... one has to be a bit careful ... >>>> >>> Yes, that is what I was thinking.  Once a userspace process does an I/O >>> and if it is based on PAGE_SIZE things can go south.  I think this is >>> not an issue with THP, so maybe it's possible with boot-time page selection? >> >> THP is a different beast and has different semantics: the base page size >> doesn't change: the result of getpagesize() is unmodified ("transparent"). >> >> One would have to emulate for a given user space process a different page >> size ... and Ryan can likely tell some stories about that. >> >> Not that I consider it reasonable to have dynamic page sizes in the kernel and >> then try emulating a different one for all user space. > > This is probably  a case of ensuring proper documentation from the distro or > application vendor. > > Or maybe some type of "Safety gate" could be implemented outside of the kernel. > Some check for the prior use of different page sizes, in the cases where it > could cause problems. I agree there are likely to be problems in some corner cases if switching page size between boots, if persisted data makes assumptions about the page size. I would argue that any problems that are observed should really be considered bugs in the user space SW though. But I don't think this is really any different from today; With Ubuntu, for example, you can install both 4K and 64K kernels concurrently, then choose which one to boot via Grub. So the issue exists there already. This proposed boot-time page size selection series, doesn't make that any worse, it just simplifies the distribution model, given the reality that distros are now having to support multiple page sizes. Thanks, Ryan