From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wr1-f41.google.com (mail-wr1-f41.google.com [209.85.221.41]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 6B68F22CBC0 for ; Thu, 10 Jul 2025 06:35:18 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.221.41 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1752129320; cv=none; b=DF6gUOUBCuuzDa0LSBuBe0qYKeF6mtuhhjQDtWQJtL5k2m0a9ifzfEFkP4m/58p7wTmZPOtqSOaQjnZRZ2hrbytRUSEu7LA4qCuMMoev1swdYj5eDKLL24aqBWqe3rxQu3Te8JML8qc3mhwvK+otQOidKHOPyeZYsQMD+FgDots= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1752129320; c=relaxed/simple; bh=ElqAfZh2BVgxfhGm74ckQk9GyfGSk4GuN3P5xEeR6vI=; h=Mime-Version:Content-Type:Date:Message-Id:From:Subject:Cc:To: References:In-Reply-To; b=Q8stPDNsdgCyeZDSa8pVQp/bIpdmpbVvV3CaKcMU4yyGUk58JueFjs+wR0wn8eY5KLb5nqMso5GIqgz+9Ofjf8LRu79i1YtN/+kPduC6bxb3wMIk721NE2FzsAxc/l3RWtcdnOUEuBvmC0apgi5fNlubrp4l3acisjgbwPfYgQ0= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=ventanamicro.com; spf=pass smtp.mailfrom=ventanamicro.com; dkim=pass (2048-bit key) header.d=ventanamicro.com header.i=@ventanamicro.com header.b=X+0uBzm3; arc=none smtp.client-ip=209.85.221.41 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=ventanamicro.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=ventanamicro.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=ventanamicro.com header.i=@ventanamicro.com header.b="X+0uBzm3" Received: by mail-wr1-f41.google.com with SMTP id ffacd0b85a97d-3a4f64cdc2dso86264f8f.1 for ; Wed, 09 Jul 2025 23:35:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ventanamicro.com; s=google; t=1752129317; x=1752734117; darn=vger.kernel.org; h=in-reply-to:references:to:cc:subject:from:message-id:date :content-transfer-encoding:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=kyhfcIGHykgvkrP2e/H7VmjAsjt0CsIijqEuhYmyjZA=; b=X+0uBzm3bi+AK1j8teGJm62HTgg3xswH/ObRCwbigjCBub6q31LIs/ErO+9bVytq0L V9UCRLl79uiw7COf3DiGJBbUvfGByyNGZPUGiaicMVFsFQ5eXV1EyTpfXUwH9WmKbSeM nh703dBsvxKH3lTYadSAcWn0ASS+7t3ObCUB71PlKHVTsaDw+49Syah/59cHUfUfcl2D uR40EpftrwRos70HsLyOA+iTOdWsNfoDmnLPzSbYLRSrNVr5j9RzeoW3OUbMVFK0u4t8 oRq/mzhJtHedOdhZYlWanarZid56shttN2rcHTjcmfu62l9w1JzPl1B2aV4KgNRznX2m HUAQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1752129317; x=1752734117; h=in-reply-to:references:to:cc:subject:from:message-id:date :content-transfer-encoding:mime-version:x-gm-message-state:from:to :cc:subject:date:message-id:reply-to; bh=kyhfcIGHykgvkrP2e/H7VmjAsjt0CsIijqEuhYmyjZA=; b=a19PKSD60LzN7PoxNH7wuRQ2EYY8t8mdwwXT4ez2bNh/6AlpvZgVuRkta0bcPj7Wcy HKyp+N82czgWWMMsT2gddQAoRGeg91e9XISYoP9m4kGlEjj8uyYKu671j36Kkjbsath7 3BEfT4OjcfZVPOqEvbY3R4OTecneui7BGroot2IWaFVDbMyJCzuZR5rZMfK1z3cQ1LxA UmaYDCj4HDd8agFqXceR3uKP6e/E0GuhNMdv1fYaVYyolPg8rKJ94tzsAdg/F5fNmnw9 Pfmn1nPNZrajmZZHqawESJVxJqhKuA5q2fimRm5UBXLcVxc71yliotAs7gAl5Vhm/Zj2 YBMA== X-Forwarded-Encrypted: i=1; AJvYcCU6MB4z9lsTdFUkwFQAsWRPd8Z0V/jRu6klnOA3GjWSjbcZZmG1q0cN1gvVAtcEzALsRsNjPPOj/mkal4c=@vger.kernel.org X-Gm-Message-State: AOJu0YxNYoLbpKD8jkaqmYcAD8T+9vHFJtrQQqNZ+j+e8L3Cmp1AaFJh CxUn7MYIya1WtSj9Au440SZnu2QrnY11vufVgBLgtUnvl5I9lqvmqC7TMYmPERhCorU= X-Gm-Gg: ASbGncsY9dpdJCyvYBn9A/0tQOJYzzPWgjqcZa/61RL2ISOzq007g5bWd3SvWxNFjT/ Z4p0N//l06Eg86+UhqOaE1XHzM2H79048VLMDobhcGzFUXQo5m2E89zf8pQn03M3w7qAW5A9FOB GJ8BhTme8NpoNFTW4cifWF2S0NoRBeg5+o/17VgT03zzEA1iFLCGmTtQYBS47g/n8GH36KlXp3e Md+fgoy69MVAZsMDOmVLfYb/Nb9jsORFGacLCN3SWvRviBufSe37m+nmLMUxoZBXD9cccLs2QE0 qMFFqKt65mfw9UvdrnrejI1YWO7uPS2FGJbjPYJbrtFpya3K0mGHfEWxIYtxZzDo7aOR9fU9+H4 JQKbuJX7yBlkbp0Rb1VMYUA== X-Google-Smtp-Source: AGHT+IEqEitaMgB8tObGyqBHxc/XW6tkIZ1LssQgO+WUWZXRaXyhTeRPn6KcRlFtzKo7i/2kYbIvaw== X-Received: by 2002:a05:600c:3584:b0:453:76e2:5b16 with SMTP id 5b1f17b1804b1-454db9090c3mr7110435e9.0.1752129316466; Wed, 09 Jul 2025 23:35:16 -0700 (PDT) Received: from localhost (ip-89-103-73-235.bb.vodafone.cz. [89.103.73.235]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-454cdb381a6sm57354855e9.1.2025.07.09.23.35.15 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 09 Jul 2025 23:35:16 -0700 (PDT) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=UTF-8 Date: Thu, 10 Jul 2025 08:35:15 +0200 Message-Id: From: =?utf-8?q?Radim_Kr=C4=8Dm=C3=A1=C5=99?= Subject: Re: [External] [PATCH] RISC-V: store percpu offset in CSR_SCRATCH Cc: , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , "linux-riscv" , To: "yunhui cui" References: <20250704084500.62688-1-cuiyunhui@bytedance.com> In-Reply-To: 2025-07-10T11:45:06+08:00, yunhui cui : > On Wed, Jul 9, 2025 at 10:20=E2=80=AFPM Radim Kr=C4=8Dm=C3=A1=C5=99 wrote: >> Is the overhead above with this patch? And when we then use the >> CSR_SCRATCH for percpu, does it degrade even further? > > We can see that the percpu optimization is around 2.5% through the > method of fixing registers, and we can consider that the percpu > optimization can bring a 2.5% gain. Is there no need to add the percpu > optimization logic on the basis of the scratch patch for testing? > > Reference: https://lists.riscv.org/g/tech-privileged/message/2485 That is when the value is in a GPR, though, and we don't know the performance of a CSR_SCRATCH access. We can hope that it's not much worse than a GPR, but an implementation might choose to be very slow with CSR_SCRATCH. I have in mind another method where we can use the current CSR_SCRATCH without changing CSR_TVAL, but I don't really want to spend time on it if reading the CSR doesn't give any benefit. It would be to store the percpu offset in CSR_SCRATCH permanently, do the early exception register shuffling with a percpu area storage, and load the thread pointer from there as well. That method would also eliminate writing CSR_SCRATCH on every exception entry+exit, so maybe it makes sense to try it even if CSRs are slow... Thanks.