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 708EEC3DA4A for ; Fri, 26 Jul 2024 16:14:14 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id E21B26B0093; Fri, 26 Jul 2024 12:14:13 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id DD19A6B009C; Fri, 26 Jul 2024 12:14:13 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C98FA6B009E; Fri, 26 Jul 2024 12:14:13 -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 AC0AA6B0093 for ; Fri, 26 Jul 2024 12:14:13 -0400 (EDT) Received: from smtpin18.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 27FE241915 for ; Fri, 26 Jul 2024 16:14:13 +0000 (UTC) X-FDA: 82382400786.18.989C832 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by imf17.hostedemail.com (Postfix) with ESMTP id 6D36D40028 for ; Fri, 26 Jul 2024 16:14:11 +0000 (UTC) Authentication-Results: imf17.hostedemail.com; dkim=none; spf=pass (imf17.hostedemail.com: domain of Dave.Martin@arm.com designates 217.140.110.172 as permitted sender) smtp.mailfrom=Dave.Martin@arm.com; dmarc=pass (policy=none) header.from=arm.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1722010401; 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=HiyxOCfvvozrwRI5Ac4AUYBp963QbEh8WQ4bZBa3TqQ=; b=h3CG4W2NlQa3PnqYsqjOacKWyulLSawei/Opiry2I7E8Xwi5LEFaeP3RqRHH1Phl6lsjAS XnYSoF+uoWjjNl+YtrwAfh0DWtINQhp+sjPJt7SPJCNcVFRs/qwb8Whg3mshNqrmjRissv bdmKrSFBxJbh9vgg8l2xmDPcIH593tc= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1722010401; a=rsa-sha256; cv=none; b=HZxRJzM2oGrSl49PZA7A0eHzUW/Vus1YxSrQibQ+5GbUICfgf0kBZV2gp8t0bCKytAJxeA JUFx42QN4SQLv8/b1hzrZbBA+nE/7nFqjDZX5uyKnR0oSPzVIJNQbg0hIZvywKXRAynJp5 v3J25dQZwD/LBSbYdCQNyhaIqOvDiKA= ARC-Authentication-Results: i=1; imf17.hostedemail.com; dkim=none; spf=pass (imf17.hostedemail.com: domain of Dave.Martin@arm.com designates 217.140.110.172 as permitted sender) smtp.mailfrom=Dave.Martin@arm.com; dmarc=pass (policy=none) header.from=arm.com 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 D2C1E1007; Fri, 26 Jul 2024 09:14:35 -0700 (PDT) Received: from e133380.arm.com (e133380.arm.com [10.1.197.55]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 3E7AB3F766; Fri, 26 Jul 2024 09:14:07 -0700 (PDT) Date: Fri, 26 Jul 2024 17:14:01 +0100 From: Dave Martin To: Mark Brown Cc: Amit Daniel Kachhap , Joey Gouly , linux-arm-kernel@lists.infradead.org, akpm@linux-foundation.org, aneesh.kumar@kernel.org, aneesh.kumar@linux.ibm.com, bp@alien8.de, catalin.marinas@arm.com, christophe.leroy@csgroup.eu, dave.hansen@linux.intel.com, hpa@zytor.com, linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, linuxppc-dev@lists.ozlabs.org, maz@kernel.org, mingo@redhat.com, mpe@ellerman.id.au, naveen.n.rao@linux.ibm.com, npiggin@gmail.com, oliver.upton@linux.dev, shuah@kernel.org, szabolcs.nagy@arm.com, tglx@linutronix.de, will@kernel.org, x86@kernel.org, kvmarm@lists.linux.dev Subject: Re: [PATCH v4 18/29] arm64: add POE signal support Message-ID: References: <20240503130147.1154804-1-joey.gouly@arm.com> <20240503130147.1154804-19-joey.gouly@arm.com> <229bd367-466e-4bf9-9627-24d2d0821ff4@arm.com> <7789da64-34e2-49db-b203-84b80e5831d5@sirena.org.uk> 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: 6D36D40028 X-Stat-Signature: ge8totxkncqyb467jokryu938owq8pbz X-HE-Tag: 1722010451-652515 X-HE-Meta: U2FsdGVkX1+TsGZOVvaHDeqYBSX0dGvGtAq7dQhsqPOo+t1BvyuuVggPQsgKgwICaSEwCDzO2e8Wt/GhcaHfk5Bp2FNeX4Y9dxqlsuQhgKWj0uZ4V+Vo+s2xXMHZF33Noc2Cru6SZGvm0sKc4KG3HjsMBXutACQiC6PSPqfXGxctoHEv8uAkWOKH402ia9LoM16zC5zSKz+nDZyx5OhO3CrQMcHoJgZYntoJo16ncConZIxSKHMnIkFY+PUhIOH20nc3q/D+xA805sbrK3PlMxpqN84J00thVwUZB64a7ITHSlBMHQG/HUSkkqa0yon7r9bAQYTXQByW4sVakv4k8e4y97FkXZG6FVftE5CX8jn87cljQhRMKQFFxPmoMg9l6VCF2if/Z5wK437D3OmvHbQoGIMAUCS3OHLGLHkr9uE+o0wBTcwnimomUao1J4u1fR6LVI65+JQE3ZD4HVzISinUeo0cARt3RMPcnTvYq7LqUvtj0JFhricPDwj9WOtCjRNG9xMvYAtjkyyMMUZ4AetG9hRLuIw2Kg6rC61OGuoZh5v7n9leXhTn54M9xH1A4Bsigj7lSZn1AD8Ow6p86gcc+/e5Ex0RKCFA21lKgUJfd/ozPkxtVlN1S6lMI3xi8gG5mgARODuxBLOrEiPz/F4JjM2v6D7dID1mV7bXv5t4v5ihj1DeVk5zG5Q/iYJqHasnMIb5B2iTEmhHyhq69K8OvtlBDv9suCHGA8TQee2ewr5Ivr2rf5+mdnwHla8YUmzJy5GydS+yNSXf5FevHh10yhHmUtQ2R3miAyhGStf/5FEON+AzJji5iCH2Cf/Ww5VtvRoJACZUB8GN/NNYOeAcYGwDP+tNcgRpWaLyT17P5qvrRe/eN3Ji/9KH2ubwUqoJ2UUhy8pNJpa34YQtEKsWviBIdECfJuLP5JyooF7h9PVyfmgYdni5M2F7bYzO6x14JiZXR2xTs9r8F9q 2kARuLhC ut9j/d8+5123Z8MMzGRcpYcdEjHQ/JJIwj3vAA0Wmq1PrtAWiZVp+UD0DvbOXpCySE+vDzMndzROW+Nb52XCQMGsIQsG88piOqNTCLsFlrLcPZDsVGzhAOcNrPNIqOVz8fJPp/pRr7vlzsGf4xUFopex6BA== 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, Jul 25, 2024 at 07:11:41PM +0100, Mark Brown wrote: > On Thu, Jul 25, 2024 at 04:58:27PM +0100, Dave Martin wrote: > > > I'll post a draft patch separately, since I think the update could > > benefit from separate discussion, but my back-of-the-envelope > > calculation suggests that (before this patch) we are down to 0x90 > > bytes of free space (i.e., over 96% full). > > > I wonder whether it is time to start pushing back on adding a new > > _foo_context for every individual register, though? > > > Maybe we could add some kind of _misc_context for miscellaneous 64-bit > > regs. > > That'd have to be a variably sized structure with pairs of sysreg > ID/value items in it I think which would be a bit of a pain to implement > but doable. The per-record header is 64 bits, we'd get maximal saving > by allocating a byte for the IDs. Or possibly the regs could be identified positionally, avoiding the need for IDs. Space would be at a premium, and we would have to think carefully about what should and should not be allowed in there. > It would be very unfortunate timing to start gating things on such a > change though (I'm particularly worried about GCS here, at this point > the kernel changes are blocking the entire ecosystem). For GCS, I wonder whether it should be made a strictly opt-in feature: i.e., if you use it then you must tolerate large sigframes, and if it is turned off then its state is neither dumped nor restored. Since GCS requires an explict prctl to turn it on, the mechanism seems partly there already in your series. I guess the GCS thread is the better place to discuss that, though. Cheers ---Dave