From owner-freebsd-hackers@freebsd.org Tue Apr 28 15:04:10 2020 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id AC1592BC03C for ; Tue, 28 Apr 2020 15:04:10 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 49BQ092b84z3LgC; Tue, 28 Apr 2020 15:04:08 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id 03SF3vli042259 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Tue, 28 Apr 2020 18:04:00 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua 03SF3vli042259 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id 03SF3vMH042258; Tue, 28 Apr 2020 18:03:57 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 28 Apr 2020 18:03:57 +0300 From: Konstantin Belousov To: Emmanuel Vadot Cc: freebsd-hackers@freebsd.org, hselasky@freebsd.org Subject: Re: Linuxkpi lock types Message-ID: <20200428150357.GX2522@kib.kiev.ua> References: <20200428164408.8de0f460c77c5f38f03fe9af@bidouilliste.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200428164408.8de0f460c77c5f38f03fe9af@bidouilliste.com> X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FORGED_GMAIL_RCVD,FREEMAIL_FROM, NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on tom.home X-Rspamd-Queue-Id: 49BQ092b84z3LgC X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=fail reason="No valid SPF, No valid DKIM" header.from=gmail.com (policy=none); spf=softfail (mx1.freebsd.org: 2001:470:d5e7:1::1 is neither permitted nor denied by domain of kostikbel@gmail.com) smtp.mailfrom=kostikbel@gmail.com X-Spamd-Result: default: False [-2.00 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; RCVD_TLS_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; FREEMAIL_FROM(0.00)[gmail.com]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; HAS_XAW(0.00)[]; R_SPF_SOFTFAIL(0.00)[~all:c]; IP_SCORE_FREEMAIL(0.00)[]; TO_DN_SOME(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; IP_SCORE(0.00)[ip: (-2.99), ipnet: 2001:470::/32(-4.65), asn: 6939(-3.60), country: US(-0.05)]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:6939, ipnet:2001:470::/32, country:US]; RCVD_COUNT_TWO(0.00)[2]; FREEMAIL_ENVFROM(0.00)[gmail.com]; DMARC_POLICY_SOFTFAIL(0.10)[gmail.com : No valid SPF, No valid DKIM,none] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2020 15:04:10 -0000 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.