[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <2759800.6ytmLjdbJ3@wuerfel>
Date: Mon, 21 Nov 2016 23:51:36 +0100
From: Arnd Bergmann <arnd@...db.de>
To: Linus Torvalds <torvalds@...ux-foundation.org>
Cc: Binoy Jayan <binoy.jayan@...aro.org>,
"linux-rdma@...r.kernel.org" <linux-rdma@...r.kernel.org>,
Mustafa Ismail <mustafa.ismail@...el.com>,
Lijun Ou <oulijun@...wei.com>,
Nicholas Bellinger <nab@...ux-iscsi.org>,
Leon Romanovsky <leonro@...lanox.com>,
target-devel <target-devel@...r.kernel.org>,
Tatyana E Nikolova <tatyana.e.nikolova@...el.com>,
Doug Ledford <dledford@...hat.com>,
Jenny Derzhavetz <jennyf@...lanox.com>,
Sagi Grimberg <sagi@...mberg.me>,
Sean Hefty <sean.hefty@...el.com>,
Faisal Latif <faisal.latif@...el.com>,
Hal Rosenstock <hal.rosenstock@...il.com>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
"Wei Hu(Xavier)" <xavier.huwei@...wei.com>,
Mark Brown <broonie@...nel.org>,
Mark Bloch <markb@...lanox.com>,
Steve Wise <swise@...ngridcomputing.com>,
Ira Weiny <ira.weiny@...el.com>,
Bart Van Assche <bart.vanassche@...disk.com>,
Matan Barak <matanb@...lanox.com>,
Sagi Grimberg <sagig@...lanox.com>
Subject: Re: [PATCH v5 2/9] IB/core: Replace semaphore sm_sem with an atomic wait
On Monday, November 21, 2016 9:57:51 AM CET Linus Torvalds wrote:
>
> - semaphores are "old-fashioned mutexes". A mutex is better than a
> semaphore, but a semaphore is better than just about all the other
> alternatives. There's nothing _wrong_ with using a semaphore per se.
>
> In this case, either use a semaphore or a mutex. If you are doing
> mutual exclusion, those are really the only two acceptable sleeping
> models.
The main problem with semaphores is that they are slowly spreading
into areas that really should be mutexes or completions. A couple
of years ago, we had only around 30 semaphores left in the kernel
and while a lot of those have been removed in the meantime, over
100 new ones have come in, the majority of them in the category
that can be trivially converted to a mutex or semaphore.
This in turn is not much of a problem, except to a certain degree
for preempt-rt users.
I suggested to Binoy that he could look into replacing the existing
semaphores one subsystem at a time under the assumption that we
could find a relatively easy alternative for every one of them
and then remove the implementation completely.
Christoph's suggestion is probably more productive here: let's
remove the ones that are obviously wrong or inferior, and only
once they have been taken care of we can look into whether it's
worth doing something about the rest or not.
Arnd
Powered by blists - more mailing lists