Date: Tue, 28 Apr 2020 18:11:31 +0200 From: Emmanuel Vadot <manu@bidouilliste.com> To: Konstantin Belousov <kostikbel@gmail.com> Cc: freebsd-hackers@freebsd.org, hselasky@freebsd.org Subject: Re: Linuxkpi lock types Message-ID: <20200428181131.7a075541001564f3a35517e8@bidouilliste.com> In-Reply-To: <20200428150357.GX2522@kib.kiev.ua> References: <20200428164408.8de0f460c77c5f38f03fe9af@bidouilliste.com> <20200428150357.GX2522@kib.kiev.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 28 Apr 2020 18:03:57 +0300 Konstantin Belousov <kostikbel@gmail.com> wrote: > 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. > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" Thanks for your answer that explain a lot of things. I guess this should be written somewhere ? A comment block in the header file of linuxkpi might be enough. -- Emmanuel Vadot <manu@bidouilliste.com> <manu@freebsd.org>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20200428181131.7a075541001564f3a35517e8>