From: Jessica Clarke <jrtc27@jrtc27.com> To: Greg KH <gregkh@linuxfoundation.org> Cc: Evan Green <evan@rivosinc.com>, Conor Dooley <conor@kernel.org>, Palmer Dabbelt <palmer@rivosinc.com>, Vineet Gupta <vineetg@rivosinc.com>, Heiko Stuebner <heiko@sntech.de>, slewis@rivosinc.com, Albert Ou <aou@eecs.berkeley.edu>, Andrew Bresticker <abrestic@rivosinc.com>, Andrew Jones <ajones@ventanamicro.com>, Anup Patel <apatel@ventanamicro.com>, Arnd Bergmann <arnd@arndb.de>, Atish Patra <atishp@rivosinc.com>, Bagas Sanjaya <bagasdotme@gmail.com>, Celeste Liu <coelacanthus@outlook.com>, Conor Dooley <conor.dooley@microchip.com>, Dao Lu <daolu@rivosinc.com>, Guo Ren <guoren@kernel.org>, Jonathan Corbet <corbet@lwn.net>, Palmer Dabbelt <palmer@dabbelt.com>, Paul Walmsley <paul.walmsley@sifive.com>, Randy Dunlap <rdunlap@infradead.org>, Ruizhe Pan <c141028@gmail.com>, Sunil V L <sunilvl@ventanamicro.com>, Tobias Klauser <tklauser@distanz.ch>, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-riscv@lists.infradead.org Subject: Re: [PATCH v2 2/6] RISC-V: Add a syscall for HW probing Date: Thu, 9 Feb 2023 17:22:09 +0000 [thread overview] Message-ID: <F4C20D57-912B-489F-A262-51EAEE79F41D@jrtc27.com> (raw) In-Reply-To: <Y+UpqHstcMahbadE@kroah.com> On 9 Feb 2023, at 17:13, Greg KH <gregkh@linuxfoundation.org> wrote: > On Thu, Feb 09, 2023 at 09:09:16AM -0800, Evan Green wrote: >> On Mon, Feb 6, 2023 at 10:32 PM Conor Dooley <conor@kernel.org> wrote: >>> >>> Hey Evan, Greg, >>> >>> >>> On 7 February 2023 06:13:39 GMT, Greg KH <gregkh@linuxfoundation.org> wrote: >>>> On Mon, Feb 06, 2023 at 12:14:51PM -0800, Evan Green wrote: >>>>> We don't have enough space for these all in ELF_HWCAP{,2} and there's no >>>>> system call that quite does this, so let's just provide an arch-specific >>>>> one to probe for hardware capabilities. This currently just provides >>>>> m{arch,imp,vendor}id, but with the key-value pairs we can pass more in >>>>> the future. >>>> >>>> Ick, this is exactly what sysfs is designed to export in a sane way. >>>> Why not just use that instead? The "key" would be the filename, and the >>>> value the value read from the filename. If the key is not present, the >>>> file is not present and it's obvious what is happening, no fancy parsing >>>> and ABI issues at all. >>> >>> https://lore.kernel.org/linux-riscv/20221201160614.xpomlqq2fzpzfmcm@kamzik/ >>> >>> This is the sysfs interface that I mentioned drew >>> suggested on the v1. >>> I think it fits ~perfectly with what Greg is suggesting too. >> >> Whoops, I'll admit I missed that comment when I reviewed the feedback >> from v1. I spent some time thinking about sysfs. The problem is this >> interface will be needed in places like very early program startup. If >> we're trying to use this in places like the ifunc selector to decide >> which memcpy to use, having to go open and read a fistful of files is >> going to be complex that early, and rough on performance. > > How is it going to be any different on "performance" than a syscall? Or > complex? It should be almost identical overall as this is all in-ram > and not any real I/o is happening. You are limited only by the speed of > your cpu. > >> Really this is data that would go great in the aux vector, except >> there's probably too much of it to justify preparing and copying into >> every new process. You could point the aux vector into a vDSO data >> area. This has the advantage of great performance and no syscall, but >> has the disadvantages of making that data ABI, and requiring it all to >> be known up front (eg the kernel can't compute any answers on the >> fly). >> >> After discussions with Palmer, my plan for the next version is to move >> this into a vDSO function plus a syscall. Private vDSO data will be >> prepped with common answers for the "all CPUs" case, avoiding the need >> for a syscall in most cases and making this fast. Since the data is >> hidden behind the vdso function, it's not ABI, which is a plus. Then >> the vdso function can fall back to the syscall for cases with exotic >> CPU masks or keys that are unknown/expensive to compute at runtime. > > I still think that's wrong, as you are wanting a set of key/values here, > which is exactly what sysfs is designed for. But this needs to be a RISC-V standard interface that can be programmed against, not something tied to highly Linux-specific things like sysfs. You’re free to implement that interface with sysfs, but exposing that as *the* interface to use would be terrible for portability. Jess > Please benchmark this first. Heck, if you don't like the > open/read/close syscall overhead, use my readfile() syscall patch that I > keep proposing every 6 months or so to remove that overhead. That would > be a good reason to get that code accepted finally :) > > thanks, > > greg k-h > > _______________________________________________ > linux-riscv mailing list > linux-riscv@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-riscv
WARNING: multiple messages have this Message-ID (diff)
From: Jessica Clarke <jrtc27@jrtc27.com> To: Greg KH <gregkh@linuxfoundation.org> Cc: Evan Green <evan@rivosinc.com>, Conor Dooley <conor@kernel.org>, Palmer Dabbelt <palmer@rivosinc.com>, Vineet Gupta <vineetg@rivosinc.com>, Heiko Stuebner <heiko@sntech.de>, slewis@rivosinc.com, Albert Ou <aou@eecs.berkeley.edu>, Andrew Bresticker <abrestic@rivosinc.com>, Andrew Jones <ajones@ventanamicro.com>, Anup Patel <apatel@ventanamicro.com>, Arnd Bergmann <arnd@arndb.de>, Atish Patra <atishp@rivosinc.com>, Bagas Sanjaya <bagasdotme@gmail.com>, Celeste Liu <coelacanthus@outlook.com>, Conor Dooley <conor.dooley@microchip.com>, Dao Lu <daolu@rivosinc.com>, Guo Ren <guoren@kernel.org>, Jonathan Corbet <corbet@lwn.net>, Palmer Dabbelt <palmer@dabbelt.com>, Paul Walmsley <paul.walmsley@sifive.com>, Randy Dunlap <rdunlap@infradead.org>, Ruizhe Pan <c141028@gmail.com>, Sunil V L <sunilvl@ventanamicro.com>, Tobias Klauser <tklauser@distanz.ch>, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-riscv@lists.infradead.org Subject: Re: [PATCH v2 2/6] RISC-V: Add a syscall for HW probing Date: Thu, 9 Feb 2023 17:22:09 +0000 [thread overview] Message-ID: <F4C20D57-912B-489F-A262-51EAEE79F41D@jrtc27.com> (raw) In-Reply-To: <Y+UpqHstcMahbadE@kroah.com> On 9 Feb 2023, at 17:13, Greg KH <gregkh@linuxfoundation.org> wrote: > On Thu, Feb 09, 2023 at 09:09:16AM -0800, Evan Green wrote: >> On Mon, Feb 6, 2023 at 10:32 PM Conor Dooley <conor@kernel.org> wrote: >>> >>> Hey Evan, Greg, >>> >>> >>> On 7 February 2023 06:13:39 GMT, Greg KH <gregkh@linuxfoundation.org> wrote: >>>> On Mon, Feb 06, 2023 at 12:14:51PM -0800, Evan Green wrote: >>>>> We don't have enough space for these all in ELF_HWCAP{,2} and there's no >>>>> system call that quite does this, so let's just provide an arch-specific >>>>> one to probe for hardware capabilities. This currently just provides >>>>> m{arch,imp,vendor}id, but with the key-value pairs we can pass more in >>>>> the future. >>>> >>>> Ick, this is exactly what sysfs is designed to export in a sane way. >>>> Why not just use that instead? The "key" would be the filename, and the >>>> value the value read from the filename. If the key is not present, the >>>> file is not present and it's obvious what is happening, no fancy parsing >>>> and ABI issues at all. >>> >>> https://lore.kernel.org/linux-riscv/20221201160614.xpomlqq2fzpzfmcm@kamzik/ >>> >>> This is the sysfs interface that I mentioned drew >>> suggested on the v1. >>> I think it fits ~perfectly with what Greg is suggesting too. >> >> Whoops, I'll admit I missed that comment when I reviewed the feedback >> from v1. I spent some time thinking about sysfs. The problem is this >> interface will be needed in places like very early program startup. If >> we're trying to use this in places like the ifunc selector to decide >> which memcpy to use, having to go open and read a fistful of files is >> going to be complex that early, and rough on performance. > > How is it going to be any different on "performance" than a syscall? Or > complex? It should be almost identical overall as this is all in-ram > and not any real I/o is happening. You are limited only by the speed of > your cpu. > >> Really this is data that would go great in the aux vector, except >> there's probably too much of it to justify preparing and copying into >> every new process. You could point the aux vector into a vDSO data >> area. This has the advantage of great performance and no syscall, but >> has the disadvantages of making that data ABI, and requiring it all to >> be known up front (eg the kernel can't compute any answers on the >> fly). >> >> After discussions with Palmer, my plan for the next version is to move >> this into a vDSO function plus a syscall. Private vDSO data will be >> prepped with common answers for the "all CPUs" case, avoiding the need >> for a syscall in most cases and making this fast. Since the data is >> hidden behind the vdso function, it's not ABI, which is a plus. Then >> the vdso function can fall back to the syscall for cases with exotic >> CPU masks or keys that are unknown/expensive to compute at runtime. > > I still think that's wrong, as you are wanting a set of key/values here, > which is exactly what sysfs is designed for. But this needs to be a RISC-V standard interface that can be programmed against, not something tied to highly Linux-specific things like sysfs. You’re free to implement that interface with sysfs, but exposing that as *the* interface to use would be terrible for portability. Jess > Please benchmark this first. Heck, if you don't like the > open/read/close syscall overhead, use my readfile() syscall patch that I > keep proposing every 6 months or so to remove that overhead. That would > be a good reason to get that code accepted finally :) > > thanks, > > greg k-h > > _______________________________________________ > linux-riscv mailing list > linux-riscv@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-riscv _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv
next prev parent reply other threads:[~2023-02-09 17:22 UTC|newest] Thread overview: 91+ messages / expand[flat|nested] mbox.gz Atom feed top 2023-02-06 20:14 [PATCH v2 0/6] RISC-V Hardware Probing User Interface Evan Green 2023-02-06 20:14 ` Evan Green 2023-02-06 20:14 ` [PATCH v2 1/6] RISC-V: Move struct riscv_cpuinfo to new header Evan Green 2023-02-06 20:14 ` Evan Green 2023-02-14 21:38 ` Conor Dooley 2023-02-14 21:38 ` Conor Dooley 2023-02-14 21:57 ` Evan Green 2023-02-14 21:57 ` Evan Green 2023-02-06 20:14 ` [PATCH v2 2/6] RISC-V: Add a syscall for HW probing Evan Green 2023-02-06 20:14 ` Evan Green 2023-02-07 6:13 ` Greg KH 2023-02-07 6:13 ` Greg KH 2023-02-07 6:32 ` Conor Dooley 2023-02-07 6:32 ` Conor Dooley 2023-02-09 17:09 ` Evan Green 2023-02-09 17:09 ` Evan Green 2023-02-09 17:13 ` Greg KH 2023-02-09 17:13 ` Greg KH 2023-02-09 17:22 ` Jessica Clarke [this message] 2023-02-09 17:22 ` Jessica Clarke 2023-02-10 6:48 ` Greg KH 2023-02-10 6:48 ` Greg KH 2023-02-09 18:41 ` Evan Green 2023-02-09 18:41 ` Evan Green 2023-02-10 6:50 ` Greg KH 2023-02-10 6:50 ` Greg KH 2023-02-07 23:16 ` kernel test robot 2023-02-07 23:16 ` kernel test robot 2023-02-14 23:51 ` Conor Dooley 2023-02-14 23:51 ` Conor Dooley 2023-02-15 8:04 ` Andrew Jones 2023-02-15 8:04 ` Andrew Jones 2023-02-15 20:49 ` Evan Green 2023-02-15 20:49 ` Evan Green 2023-02-15 21:10 ` Conor Dooley 2023-02-15 21:10 ` Conor Dooley 2023-02-15 9:56 ` Arnd Bergmann 2023-02-15 9:56 ` Arnd Bergmann 2023-02-15 21:14 ` Evan Green 2023-02-15 21:14 ` Evan Green 2023-02-15 22:43 ` Jessica Clarke 2023-02-15 22:43 ` Jessica Clarke 2023-02-16 13:28 ` Arnd Bergmann 2023-02-16 13:28 ` Arnd Bergmann 2023-02-16 23:18 ` Evan Green 2023-02-16 23:18 ` Evan Green 2023-02-06 20:14 ` [PATCH v2 3/6] RISC-V: hwprobe: Add support for RISCV_HWPROBE_BASE_BEHAVIOR_IMA Evan Green 2023-02-06 20:14 ` Evan Green 2023-02-08 5:06 ` kernel test robot 2023-02-15 21:25 ` Conor Dooley 2023-02-15 21:25 ` Conor Dooley 2023-02-15 22:09 ` Conor Dooley 2023-02-15 22:09 ` Conor Dooley 2023-02-06 20:14 ` [PATCH v2 4/6] dt-bindings: Add RISC-V misaligned access performance Evan Green 2023-02-06 20:14 ` Evan Green 2023-02-06 21:49 ` Rob Herring 2023-02-06 21:49 ` Rob Herring 2023-02-07 17:05 ` Rob Herring 2023-02-07 17:05 ` Rob Herring 2023-02-08 12:45 ` David Laight 2023-02-08 12:45 ` David Laight 2023-02-09 16:51 ` Palmer Dabbelt 2023-02-09 16:51 ` Palmer Dabbelt 2023-02-28 14:56 ` Rob Herring 2023-02-28 14:56 ` Rob Herring 2023-02-14 21:26 ` Conor Dooley 2023-02-14 21:26 ` Conor Dooley 2023-02-15 20:50 ` Evan Green 2023-02-15 20:50 ` Evan Green 2023-02-06 20:14 ` [PATCH v2 5/6] RISC-V: hwprobe: Support probing of " Evan Green 2023-02-06 20:14 ` Evan Green 2023-02-07 7:02 ` kernel test robot 2023-02-07 7:02 ` kernel test robot 2023-02-15 21:57 ` Conor Dooley 2023-02-15 21:57 ` Conor Dooley 2023-02-18 0:15 ` Evan Green 2023-02-18 0:15 ` Evan Green 2023-02-06 20:14 ` [PATCH v2 6/6] selftests: Test the new RISC-V hwprobe interface Evan Green 2023-02-06 20:14 ` Evan Green 2023-02-06 21:27 ` Mark Brown 2023-02-06 21:27 ` Mark Brown 2023-02-09 18:44 ` Evan Green 2023-02-09 18:44 ` Evan Green 2023-02-06 21:11 ` [PATCH v2 0/6] RISC-V Hardware Probing User Interface Jessica Clarke 2023-02-06 21:11 ` Jessica Clarke 2023-02-06 22:47 ` Heinrich Schuchardt 2023-02-06 22:47 ` Heinrich Schuchardt 2023-02-09 16:56 ` Palmer Dabbelt 2023-02-09 16:56 ` Palmer Dabbelt 2023-02-06 22:32 ` Conor Dooley 2023-02-06 22:32 ` Conor Dooley
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=F4C20D57-912B-489F-A262-51EAEE79F41D@jrtc27.com \ --to=jrtc27@jrtc27.com \ --cc=abrestic@rivosinc.com \ --cc=ajones@ventanamicro.com \ --cc=aou@eecs.berkeley.edu \ --cc=apatel@ventanamicro.com \ --cc=arnd@arndb.de \ --cc=atishp@rivosinc.com \ --cc=bagasdotme@gmail.com \ --cc=c141028@gmail.com \ --cc=coelacanthus@outlook.com \ --cc=conor.dooley@microchip.com \ --cc=conor@kernel.org \ --cc=corbet@lwn.net \ --cc=daolu@rivosinc.com \ --cc=evan@rivosinc.com \ --cc=gregkh@linuxfoundation.org \ --cc=guoren@kernel.org \ --cc=heiko@sntech.de \ --cc=linux-doc@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-riscv@lists.infradead.org \ --cc=palmer@dabbelt.com \ --cc=palmer@rivosinc.com \ --cc=paul.walmsley@sifive.com \ --cc=rdunlap@infradead.org \ --cc=slewis@rivosinc.com \ --cc=sunilvl@ventanamicro.com \ --cc=tklauser@distanz.ch \ --cc=vineetg@rivosinc.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.