On Tue, Jan 21, 2025 at 3:34 AM Mateusz Guzik <mjguzik@xxxxxxxxx> wrote: > Most of the time when something was done it is either because it's a bad > idea or (more likely) nobody sat down to do it. Ok thanks for this. Realistically seeing if theres a real answer here was the main hope of my post, but I'm assuming you're probably correct here. > > Note that pipes allow for an arbitrary number of readers and writers. > This is used in practice by make for example. > > kfifo code you are mentioning explicitly requires locking for that to > work. > > Also note that consumers are allowed to perform arbitrarily sized ops. > > Maybe some hackery could be done to speed things up on this front > (per-buffer locking or somehow detecting there can't be more than one > reader and writer?), but I don't see a good way here. > My understanding of kfifo is that read and write operations have to be locked at their respective end when there is more than one reader or writer, but the data structure doesn't have to be globally locked. This could be accomplished with spinlocks for both ends similar to use in kfifo_in_spinlocked etc. Pipes already keep track of the number of readers or writers, and could use the non-spinlocked path in SPSC situations. My assumption is that a majority of pipe usage is in SPSC situations so allowing for this much faster version seems desirable. > > Can you show your code? I don't have this mocked out in the kernel yet but my plan is to attempt this over the next week or so. Thank you for your comments!
