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 884AFC25B46 for ; Mon, 23 Oct 2023 17:08:35 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 1F43F6B0127; Mon, 23 Oct 2023 13:08:35 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 1A42F6B0128; Mon, 23 Oct 2023 13:08:35 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 0935A6B0129; Mon, 23 Oct 2023 13:08:35 -0400 (EDT) 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 ECEE16B0127 for ; Mon, 23 Oct 2023 13:08:34 -0400 (EDT) Received: from smtpin20.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id C50091A030A for ; Mon, 23 Oct 2023 17:08:34 +0000 (UTC) X-FDA: 81377360148.20.E234DE4 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf10.hostedemail.com (Postfix) with ESMTP id 117C6C000F for ; Mon, 23 Oct 2023 17:08:31 +0000 (UTC) Authentication-Results: imf10.hostedemail.com; dkim=none; spf=pass (imf10.hostedemail.com: domain of cmarinas@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=cmarinas@kernel.org; dmarc=fail reason="SPF not aligned (relaxed), No valid DKIM" header.from=arm.com (policy=none) ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1698080912; 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; bh=THF0re05WZ1UGLXn2a9ASKWd0QScSjUwIesgDWAQxWA=; b=RnSBNwLaYc8YeDFmdRhzBMZVvlfnytRG1vTR6R+UDsjOTZBEyHrs882f2seFTCmy0+ihpR WSLWtfr16NRrzdqh+BPyiBLMbl4uCtgxzGaHGvctZZYWJclQSl48nN+qKrBY2dqYIaIqs6 em4elVCIidvL16iSqeWQVgPsOJ6fBNU= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1698080912; a=rsa-sha256; cv=none; b=ik/RZZTZD54ridOS9ZfKwhAWb+39ai8rQO/JNpAKMBO4wVrFhUmDC7/MJ5d84Qom8KCqUi 6ijMJ6gJqHnBQfK42jP78fryQdpNoo/rj2InZ4d/zCePdd5jpbZJT7bPKfmHnUGaO/VLkM votph7V2hzmue2nmZD11/gyz8gRJHQU= ARC-Authentication-Results: i=1; imf10.hostedemail.com; dkim=none; spf=pass (imf10.hostedemail.com: domain of cmarinas@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=cmarinas@kernel.org; dmarc=fail reason="SPF not aligned (relaxed), No valid DKIM" header.from=arm.com (policy=none) Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id 1A60A625E4; Mon, 23 Oct 2023 17:08:31 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 3EBAEC433C8; Mon, 23 Oct 2023 17:08:24 +0000 (UTC) Date: Mon, 23 Oct 2023 18:08:21 +0100 From: Catalin Marinas To: David Hildenbrand Cc: Hyesoo Yu , Alexandru Elisei , will@kernel.org, oliver.upton@linux.dev, maz@kernel.org, james.morse@arm.com, suzuki.poulose@arm.com, yuzenghui@huawei.com, arnd@arndb.de, akpm@linux-foundation.org, mingo@redhat.com, peterz@infradead.org, juri.lelli@redhat.com, vincent.guittot@linaro.org, dietmar.eggemann@arm.com, rostedt@goodmis.org, bsegall@google.com, mgorman@suse.de, bristot@redhat.com, vschneid@redhat.com, mhiramat@kernel.org, rppt@kernel.org, hughd@google.com, pcc@google.com, steven.price@arm.com, anshuman.khandual@arm.com, vincenzo.frascino@arm.com, eugenis@google.com, kcc@google.com, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, kvmarm@lists.linux.dev, linux-fsdevel@vger.kernel.org, linux-arch@vger.kernel.org, linux-mm@kvack.org Subject: Re: [PATCH RFC 06/37] mm: page_alloc: Allocate from movable pcp lists only if ALLOC_FROM_METADATA Message-ID: References: <20230823131350.114942-1-alexandru.elisei@arm.com> <20230823131350.114942-7-alexandru.elisei@arm.com> <20231010074823.GA2536665@tiffany> <20231023071656.GA344850@tiffany> <25fad62e-b1d9-4d63-9d95-08c010756231@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <25fad62e-b1d9-4d63-9d95-08c010756231@redhat.com> X-Stat-Signature: hkzseow8j4yjhyn4circ65i1oabujy3k X-Rspamd-Server: rspam10 X-Rspamd-Queue-Id: 117C6C000F X-Rspam-User: X-HE-Tag: 1698080911-817269 X-HE-Meta: U2FsdGVkX1+TMRd3IA2ZV9G792+lbwZ4rgpibVa5QV46eajytll9u/hP4oDkQLSn85v3rZPPJXPdD0oF9O1iW6h1JJJt2y1vFbiAibcZJN+tc+yZZSXXbk4Mh7mY612nJ4eEc62iidmu25iNTrU+WygABzcyq3QZXMhyMg/wRJDTA5XGVp4WoUXCTUGxgrYbfl/NgL0DBIHpd3GMy1YWOpvB0G/QM28yQA3Zs5sXnxmmLrHJQ8cuMB47HXXCMZJuC59c5QIt8AscEkkVuTISbXoT4NP2DA/1macc3U7rOxldt/C75/PUBsVTGqTGw/o1c2l3Nujs8DHP44cFuBNL8qqY4kcerjHdoNDrKSnrOBfNY9CjApmTlx7t7eX3KtqQlPSg72Gf56jQx+p8ZR8EgUIvPF1MRmevfj5YW3vSMqVg2y+hAkVt+kEmFbpY47ItmrZ3FeiN/SjVBaq+RdyU3b1GQN3hjE94LgmrXXnwI56mUelkb2gW3gv4EunkDdCnbYMyYAjV5BC4guXs6w3urHqleCUdUlw8kcNIweysDLsMSjZz798mPodWe/zFtSjz3yHC/VMd1IQX1ihWCRKxlrQZv2XoIBfNUpRv5+BSoEmWKzTtnHU3UDwvB0rM7HNugHTogmtMFZJRMKBbnqJrZ7h8xr0FTlBuNWkHBHd52Nwgke99WAMyl7HvvHa0iWK3mLe2LoWQI46WMLq9TwCELeT8RsalYIKByww9uoBoj5TBR+yBrkeYMWrlXaHS8HEHMoZIc745rPBRHBnopvswopniFaZ+tc+x02xihbeACR7LB/JMIMudZWx92iVOFCv5GotY/cBdjnigi5FYBiZXzs8DERNhACuwBRoSijWlSHh3ZFtzuGFJUD+2SNqODEeIykDNWZ3HwhucebWRos/pXHdovy93Z0o6rOtW1e2oaQjVHD7ct1gqLmeI6ErzAQXgOZgTlNEcCkJQLPGtZaB XNnAU5R1 wiM6nqkpr46dR0rspaG+iUMMGh7OTzjNWG0CWI65oHSKut97jreOLb/IbDN2VrGsRcXtpvgdHHZCuXQ0BPQZHJrNJcZjx6tfd21fpaRv3u/ugfJa5PmUe3/is+8v+r4VZwFw1Pq9q/6TCbIMoPlDg20DRuxfGM2Uo85hDe3Z7ZbS/H3GfGzQ9X/zYmLlVb/Buk1FMVwn9WUjTbaLjs2DafiY96PWaD71SPSY+UVQoE7Vm1Md4+ZNm9vQxXVDw13iNTFjOvHLQNp81up+KcvB7fxt0kxRvjPmLUKM2/TPTQj3j0r/PCMDTsWqQ+PkmvpoQ824a9o1UYCBBAjY5+Fmub1kIfc8KyyfxzmE+K9E4mnywjR1amAMHNdeDbBOOqI5xR6301o8ZzxTtSa0= 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 Mon, Oct 23, 2023 at 01:55:12PM +0200, David Hildenbrand wrote: > On 23.10.23 12:50, Catalin Marinas wrote: > > On Mon, Oct 23, 2023 at 04:16:56PM +0900, Hyesoo Yu wrote: > > > Does tag storage itself supports tagging? Will the following version be unusable > > > if the hardware does not support it? The document of google said that > > > "If this memory is itself mapped as Tagged Normal (which should not happen!) > > > then tag updates on it either raise a fault or do nothing, but never change the > > > contents of any other page." > > > (https://github.com/google/sanitizers/blob/master/mte-dynamic-carveout/spec.md) > > > > > > The support of H/W is very welcome because it is good to make the patches simpler. > > > But if H/W doesn't support it, Can't the new solution be used? > > > > AFAIK on the current interconnects this is supported but the offsets > > will need to be configured by firmware in such a way that a tag access > > to the tag carve-out range still points to physical RAM, otherwise, as > > per Google's doc, you can get some unexpected behaviour. [...] > I followed what you are saying, but I didn't quite read the following > clearly stated in your calculations: Using this model, how much memory would > you be able to reuse, and how much not? > > I suspect you would *not* be able to reuse "1/(32*32)" [second carve-out] > but be able to reuse "1/32 - 1/(32*32)" [first carve-out] or am I completely > off? That's correct. In theory, from the hardware perspective, we could even go recursively to the third/fourth etc. carveout until the last one is a single page but I'd rather not complicate things further. > Further, (just thinking about it) I assume you've taken care of the > condition that memory cannot self-host it's own tag memory. So that cannot > happen in the model proposed here, right? I don't fully understand what you mean. The tags for the first data range (0 .. ram_size * 31/32) are stored in the first tag carveout. That's where we'll need CMA. For the tag carveout, when hosting data pages as tagged, the tags go in the second carveout which is fully reserved (still TBD but possibly the firmware won't even tell the kernel about it). -- Catalin