From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-dy1-f182.google.com (mail-dy1-f182.google.com [74.125.82.182]) (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 919B238642C for ; Thu, 21 May 2026 19:15:22 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=74.125.82.182 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779390926; cv=none; b=bXDqCu7i9auWnMPO6WzuEB8WpNXnelW58aS4y8QdN576TTr8EUFy/NLx2hhA9Jsg8+Q0E+rHg+IYblHaBRdmdWOkHlAIudEUYIsUfjlgISiHFlrPDkoAKzsjfGBBV/VLMn5rUyuXUZcUWf//ZZG26k8hdE3ftGiDB6qFDwWG3uw= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779390926; c=relaxed/simple; bh=Q290mwWNbgrqJQBnMmZpkg03X3tH7Y2ll2leJcMVQKw=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=b1liOPa3FO/2pIf3ZSotO10vDezB0yiemEZSFgupJ5LIh1ui7pp18gpVxfZOBSFa57qp8LXnC+4vf+AoM2PomqQAWzSsdRa8JMtXSVXkNRWOur5Zye0huTEa/nr2yk0luD8XBPe84CRx8jKDm9cAP5lHTFbQDv/GJPNrIGRO4Cg= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=lixom.net; spf=none smtp.mailfrom=lixom.net; dkim=pass (2048-bit key) header.d=lixom-net.20251104.gappssmtp.com header.i=@lixom-net.20251104.gappssmtp.com header.b=RNHkG/fc; arc=none smtp.client-ip=74.125.82.182 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=lixom.net Authentication-Results: smtp.subspace.kernel.org; spf=none smtp.mailfrom=lixom.net Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=lixom-net.20251104.gappssmtp.com header.i=@lixom-net.20251104.gappssmtp.com header.b="RNHkG/fc" Received: by mail-dy1-f182.google.com with SMTP id 5a478bee46e88-303dbfbec77so7120032eec.0 for ; Thu, 21 May 2026 12:15:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lixom-net.20251104.gappssmtp.com; s=20251104; t=1779390920; x=1779995720; darn=vger.kernel.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=ZOjqZYfGW+XMqudCuPdau+DWasuYcTuRfgL+xBmaWTE=; b=RNHkG/fcvz5YGz14Bgw/eoeHSRHKazxX7zG89FoY1cSHJykU/xdtcSLJ0TDmoW5Yo3 fCSGRPbEbJqLpZzZjYKFX5tvL+Vj5JU+DAWhX/U//F3dktgX0Ln+0sb5ouBB43lQqh2i HBOBGTIW7hVL6kBBLrr6dq0AA8FJJBjzXGmoGcyMabqt9T8qJ6bjOzDmBl0dEro5WONb r+G25PxPKVtw3YVj5yzhtZJd0lrUSWczdpijv/2sEsh6DUJcTzg7t6l5vZHZVrl5+Vmt dbO/Zdf1+JWzPGLZp+KySd55bISmhgYFsXrxfSp6Zyr7mbrupWXVhb1Nks0CNp+zL4Vi Wv8Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1779390920; x=1779995720; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=ZOjqZYfGW+XMqudCuPdau+DWasuYcTuRfgL+xBmaWTE=; b=FfxdUCNxoRFMNhgIt6tQ7oyq5OHzC7BpMxaX1ijHrhwSyYmDqpZRjcVc8mMZ1vjxMi rpmjEfxnGVbpy2GFOKJD876G43J009Q1688QQqNDfvVjX7P3Z8AZRBOzeSNS20e0/fSX x7/KglxedaClzbEG4J4g06XNeUc7ZQ89QkogcntS1emg50UjZT08Nn8O6KGecUU7wWM4 ME3kYuuHyq3ZUNTuq2eP17bHECIc3Ty3nGw0WyusOkacryVcqCQS7N4DJ7tMlsQFpmSN MHOpf7hu3zhUVHxbLfQ0Tu5feYpRLz++tT22X5wk1YJKNG8BjpT6PmkFLdkzG5v7Ti12 9eJA== X-Forwarded-Encrypted: i=1; AFNElJ8ZVmlvUMa62uMhlVXVEEyd/nCCfqwl+o15IsAllJTn7MaKklZ4V0/pBHGiikKaJVamMduu+6FFyvxN39U=@vger.kernel.org X-Gm-Message-State: AOJu0YxyRGWfrl+Xx8svJ9OkU46aeKczRt3hMs8WSOkLONU7g/VA3P/F ADClbRjfkFAGtbuJoJqyXXP2l7dkhVXvpWtOPMcs7Fa4pfiafnyqc2eVyB5lLhFqivE6DNuMiXd OYrYs9oI= X-Gm-Gg: Acq92OFBLVsox28J3CZAQmcSAIbSwB3eslwjPadn1yNFV5h9QrQvGCjWEcasMfF4nkv N5qkekqih7OKw5DZdEao+uEkojgTRmn3h3ors9eFEMecL0WbBB4iBb8OkZFojw5BtXluJZ0Rcda PeW4s92UPS1Z0AjzeB3+9yrzzsBP5FOEJlsS7yWArn2jGNheyB7zgI8CsDn5lJmaMNLtjudUXv1 PUhBWzIESypSzIU6sIOVQQG3EIcAuFP9h6i9TuRrB1ZBPJS8GiobtaFQKOTlB54HIq0CHO6V1gz HDq5dqIBWE5yPiuVuh/qKjv6rSl0lElBmfx7IeoR2PM+85tUmoafnUeGP7Bwci+skrzBNEk9LyI PIpXMUcHSxgm544e57I4yTPoQxxbXEcYbeFeonkDf8xhELDcG3GKi0Gg4ImWj0tn7NoFAK+0cyd cQvhlOqDCkK3jD X-Received: by 2002:a05:7300:3720:b0:2dd:8ac2:9f7a with SMTP id 5a478bee46e88-30448f4ad54mr309655eec.11.1779390919456; Thu, 21 May 2026 12:15:19 -0700 (PDT) Received: from localhost ([99.152.116.91]) by smtp.gmail.com with UTF8SMTPSA id 5a478bee46e88-304435c2ea0sm1186983eec.31.2026.05.21.12.15.18 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 21 May 2026 12:15:18 -0700 (PDT) Date: Thu, 21 May 2026 12:15:07 -0700 From: Olof Johansson To: Andy Chiu Cc: Paul Walmsley , Palmer Dabbelt , Albert Ou , Alexandre Ghiti , linux-riscv@lists.infradead.org, dfustini@oss.tenstorrent.com, bjorn@kernel.org, greentime.hu@sifive.com, vincent.chen@sifive.com, linux-kernel@vger.kernel.org Subject: Re: [PATCH v3 0/4] riscv: optimize Vector context restore on syscall Message-ID: References: <20260521162521.188629-1-tchiu@tenstorrent.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20260521162521.188629-1-tchiu@tenstorrent.com> Hi Andy, On Thu, May 21, 2026 at 11:25:16AM -0500, Andy Chiu wrote: > This patch series optimizes riscv vector state handling across syscall > boundaries and context switches. The kernel now keeps track of the > INITIAL state in sstatus.vs to optimize unnecessary context management > operations. > > This version merges daichengrong's RFC patch [1] for the state tracking > code as it looks cleaner than my v2/v1. > > [1]: https://lore.kernel.org/linux-riscv/7ba2f4b7-8475-4ec3-ab31-58b332bda47e@iscas.ac.cn/#r > Link to v2: https://lore.kernel.org/linux-riscv/20260402043414.2421916-1-andybnac@gmail.com/ A patchset like this would be really helped by some kind of numbers in the cover letter to indicate how much performance moved, given a claim of optimization. Just for kicks I tried a simple microbenchmark for syscalls from a vector-enabled process: #define _GNU_SOURCE #include #include #include #include #include #include static inline uint64_t ns_now(void) { struct timespec t; clock_gettime(CLOCK_MONOTONIC, &t); return t.tv_sec * 1000000000ull + t.tv_nsec; } int main(int argc, char **argv) { int iters = argc > 1 ? atoi(argv[1]) : 10000000; int use_v = argc > 2 ? atoi(argv[2]) : 1; if (use_v) { asm volatile( ".option push\n\t.option arch, +v\n\t" "vsetivli x0, 1, e32, m1, ta, ma\n\t" "vmv.v.i v0, 1\n\t" ".option pop\n\t" ::: "memory"); } for (int i = 0; i < 10000; i++) syscall(SYS_getppid); // warmup uint64_t t0 = ns_now(); for (int i = 0; i < iters; i++) syscall(SYS_getppid); uint64_t t1 = ns_now(); printf("V=%d %.1f ns/call (%lu ns / %d iters)\n", use_v, (double)(t1 - t0) / iters, t1 - t0, iters); return 0; } I compiled with gcc -O3, default GCC 14.2 on Debian 13. Host is x280 (Blackhole). Base kernel sources is 7.1.0-rc4-next-20260520 defconfig. Ran with taskset to pin to one of the CPUs. The testcase doesn't use vector inbetween each syscall, but will obviously have initiated the state (if started with '1' as second argument). Without this patchset: V=1 242.9 ns/call (12144527848 ns / 50000000 iters) With this patchset: V=1 264.5 ns/call (13226852900 ns / 50000000 iters) Interestingly enough, with V=0 test it sped up slightly (194.3 -> 189.5 ns). I repeated the runs a few times, with similar results so I don't think it's explainable as noise. Given that more code will be vector enabled in the new shiny RVA23 world we are entering, I'm uncertain whether this is the right trade-off. You won't get the syscall perf cost returned unless you need the vector context swapped in without the lazy fault between calls. I suspect running userspace workloads on a RVA23 platform (SpaceMIT K3) with Ubuntu 26.04 would be the most meaningful data to collect. My ordered board is still in shipping, unfortunately. PS: There's a new build warning due to an unused 'uvstate' variable in riscv_v_start_kernel_context() that you might want to fix. -Olof