Messages in this thread | | | Date | Mon, 14 Apr 2008 09:56:38 -0700 | From | Arjan van de Ven <> | Subject | Re: [PATCH] Replace completions with semaphores |
| |
On Mon, 14 Apr 2008 18:32:28 +0200 Peter Zijlstra <peterz@infradead.org> wrote:
> On Mon, 2008-04-14 at 08:58 -0700, Roland Dreier wrote: > > > which ones exactly are these places that demand the use of a > > > counting > > > semaphore? I cannot think of a single place where it's the best > > > choice, let alone one where it's the only choice. > > > > Two of the places that use semaphores are > > drivers/infiniband/hw/mthca and drivers/net/mlx4 -- in both cases, > > the device firmware allows up to "N" outstanding firmware commands > > to be in flight, and the driver uses a semaphore to handle issuing > > firmware commands. That is, down() when we want to issue a > > command, and up() when the firmware responds that the command is > > complete. > > > > What would you suggest as a better way to code this? This is an > > honest question -- there probably is a more elegant way to handle > > this situation and I really would like to learn about it. > > > > Also, the argument that removing semaphores makes the kernel as a > > whole better does make sense to me; I wouldn't be opposed to > > basically open-coding semaphores in terms of wait_event() in the > > driver or something like that, but I wouldn't say that such an > > implementation is locally more readable or maintainable if we look > > only at the driver code. > > Yeah, I would open code it. But this is indeed a sane usage of the > counting semaphore because there is no priority inversion.
Maybe we need a "counter" primitive instead? From a conceptual point of view that even makes sense
(the implementation can be pretty much the current semaphore one of course)
-- If you want to reach me at my work email, use arjan@linux.intel.com For development, discussion and tips for power savings, visit http://www.lesswatts.org
| |