Date: Tue, 28 Apr 2020 18:03:57 +0300 From: Konstantin Belousov <kostikbel@gmail.com> To: Emmanuel Vadot <manu@bidouilliste.com> Cc: freebsd-hackers@freebsd.org, hselasky@freebsd.org Subject: Re: Linuxkpi lock types Message-ID: <20200428150357.GX2522@kib.kiev.ua> In-Reply-To: <20200428164408.8de0f460c77c5f38f03fe9af@bidouilliste.com> References: <20200428164408.8de0f460c77c5f38f03fe9af@bidouilliste.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Apr 28, 2020 at 04:44:08PM +0200, Emmanuel Vadot wrote: > > Hello, > > I was looking at the linuxkpi locks and notice something that I don't > understand. > > For linux struct mutex we use or sx locks but looking at the doc in > linux (Documentation/locking/mutex-design.rst) it seems that those are > almost 1:1 our mtx, is there a reason that sx where chosen ? > For the linux spinlocks we use MTX_DEF lock, which doesn't seems right > at all so same question. > > Thanks for your answers, Linux spinlocks must protect interrupt handlers. Since Linuxkpi runs handlers threaded, they should (or must) use normal mutexes in FreeBSD land, so translation of spinlocks to mutexes is fine. If handlers were non-threaded but fast, then linux spinlocks-> FreeBSD mtx_spin is somewhat reasonable, but I believe that Linux interrupt handlers might try to do things like memory allocation which cannot work from FreeBSD fast handlers. Also, running handlers with interrupts enabled improves system responsibility to other events. After spinlocks are translated to sleepable mutexes, it is natural to convert sleepable Linux mutexes to sx'es. I do not think that Linux mutexes provide priority propagation (but I can be wrong), which matches sx behaviour. Also sx provide some more required features like interruptible sleep, which mtx lacks. In other words, it all starts with the decision to run interrupt handlers threaded as most FreeBSD drivers do, and then it is logical to 'step up' each locking primitive. I have some memories the realtime Linux patches did the same.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20200428150357.GX2522>