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 A35AEC3DA61 for ; Mon, 29 Jul 2024 14:27:24 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 36B1E6B0095; Mon, 29 Jul 2024 10:27:24 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 31B446B0099; Mon, 29 Jul 2024 10:27:24 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1E38D6B009A; Mon, 29 Jul 2024 10:27:24 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id F13B26B0095 for ; Mon, 29 Jul 2024 10:27:23 -0400 (EDT) Received: from smtpin08.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id A50AF8033A for ; Mon, 29 Jul 2024 14:27:23 +0000 (UTC) X-FDA: 82393017966.08.E6CF5EE Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by imf14.hostedemail.com (Postfix) with ESMTP id C4BBA100008 for ; Mon, 29 Jul 2024 14:27:21 +0000 (UTC) Authentication-Results: imf14.hostedemail.com; dkim=none; spf=pass (imf14.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=1722263188; 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=euoVfaH0pl1j6MQqF7l10BPqvhNZE8HrS/jqfgkzbCs=; b=L3duI7sMXEg5Noy5nJpN7B4byEaNGLce9GFkuqJ5ZwCYXvE7ixQvu5Esk+b33mDUQHk7OA Q14xaxDBRobyaITAKwO7NnrgnVjmL2x0tXniJOL8iS00+xGR1zH7p7nttcTaKelSMApAAB xh+f3zdR9lXAieIL8hAuDuH8tsKDtno= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1722263188; a=rsa-sha256; cv=none; b=0KWusmDCgqzOjLhSefxWkshCKgam0QPGdOMF6zFewn5TbmSpXnKTIb9P7Jh7tLEVu6x5uR 7Bc0Y/k5P6mlo/Be5XPuBPIyIJqrDTZSbdFeJZ7zmJtFRE+EKX9wqyGUZMLcLkNR8kpGfJ wB9eSHmHUkwd46k+fn3iMdLqOuwSd78= ARC-Authentication-Results: i=1; imf14.hostedemail.com; dkim=none; spf=pass (imf14.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 38AA21007; Mon, 29 Jul 2024 07:27:46 -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 CD7413F64C; Mon, 29 Jul 2024 07:27:16 -0700 (PDT) Date: Mon, 29 Jul 2024 15:27:11 +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-Stat-Signature: z3y7nn61okfqxc1h6nrppf1951n5kpx9 X-Rspamd-Queue-Id: C4BBA100008 X-Rspam-User: X-Rspamd-Server: rspam08 X-HE-Tag: 1722263241-378960 X-HE-Meta: U2FsdGVkX1+ydlwH1fBe3LtZp8QGAbWqR6HcLhSiTI2c80wmi5lfNzV4LhrlKjgSOPRSI2zlT4xC4pC6fS/UB6vCilJAROMWGI4p1Y0/oYpW8BjMmCgMWGPBuuubnMrhncfS8uQKzpBMQmEGpNrRFC67OJtY3y3LbGvl5Zu6XZh3zvlPZPfCEN2/s/AH5VdNi3XLJ8n0IYk0iPjqMAQS70jjXcqxsLn2hg6VFZ/pd93ncj7efovOnCDWOftVpzpXSKXS0PDl2i1eHOLVWL4hFz9sDeIDe9L9Vin6aD8krT26NyHj3xlawH/IWwKM6uGpNMF4u7iXsORSorp5zSqMSoT6uDj4g2J1FF/8n42Ka6RqSLqe6uh7KoeQum4UzhXMrHyaqCS/7xIHKJ3YBM25shJRCOwPgYopuPmZdcygpQzuJvfgJz1zrvT2IV/jqdMKt/UN1BehFQT4gzzUt8xyCj1wQ0Sh2tLE/933+Is7vwlUjd5O1REpB/44LJNvYuHs5Qq5g5G/WzysEAQ9hObJ26+cczWsy3YKxnrMk2ook+PvSRpA8CgyqkLhTnJBW0tnbDaq+VZ4KRMVd5kBcAgLiCUCyroSfHv43lAoR/IDSKbXaW89L1jxFNiYAVqJp6X8lR4e7/OjanWWBJpC6HmM5GotGNIYVzMmebsTunhJsLmq8ZLU8WhfE4dz7ac18uLBlz5U5XUMZ86PYznn7Ok8ZzaqFflukxdVYGJOmyvdFD11aXTFh+z1ki95/lGC9rYB3QxChl7kQ9ql2ykILrXx7FYABm1mYS+kHPHJvfMfMREe+DzQGu2/S0xx70UF+DuFr2/u/qN3FxSQa5Qly/qWKZZdPFlpkG8Qu4q1y81v+xxazoYZBv44McBPXEJG/KhK5oHS9hrYuyDyEJR2b6P0uhjWbO0Uc+qBQX6xwIBVxhooxte5WMEm20QbL8IzFtACKtfMXTminnoHpTpeOml 0FRq62e1 3UDAxD1lViZaUKUgqJNB2y4nVumJeVxd8UIomoMbnn9+SQl/UiAlxl22KdYgoqlWJXbWYvJAK0YlVSrmtcHljiCdC0WsjckKiOks64Hts8xzTYTThPko1zqx0daZlCtx5bugzqvQL0HYs6UjWp5rh94f/tw== 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 Fri, Jul 26, 2024 at 06:39:27PM +0100, Mark Brown wrote: > On Fri, Jul 26, 2024 at 05:14:01PM +0100, Dave Martin wrote: > > On Thu, Jul 25, 2024 at 07:11:41PM +0100, Mark Brown wrote: > > > > 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. > > Yes, though that would mean if we had to generate any register in there > we'd always have to generate at least as many entries as whatever number > it got assigned which depending on how much optionality ends up getting > used might be unfortunate. Ack, though it's only 150 bytes or so at most, so just zeroing it all (or as much as we know about) doesn't feel like a big cost. It depends how determined we are to squeeze the most out of the remaining space. > > > 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. > > Yeah, that's what the current code does actually. In any case it's not > just a single register - there's also the GCS mode in there. Agreed -- I'll ping the GCS series, but this sounds like a reasonable starting point. Cheers ---Dave