On Mon, Jan 20, 2025 at 07:08:43PM -0500, Nick Renner wrote: > I've been conducting research using a libraryOS that I've designed > that uses a mutex free FIFO to implement pipes while adhering to > Linux's API. I found that this can increase throughput by close to 3X, > and that most of the overhead is due to the pipe's mutex preventing > concurrent writes and reads. I see that there is a similar > implementation to this used in the kernel provided in kfifo.h which > could possibly be used to improve this. > 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. 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. There is definitely performance left on the table, I just doubt something can be done to parallelize this in a sensible manner which helps in the real-world. Happy to be proven wrong. :) Can you show your code? That's my non-maintainer $0,03.
