From owner-freebsd-hackers@freebsd.org Tue Apr 28 16:11:38 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 0FB8A2BE613 for ; Tue, 28 Apr 2020 16:11:38 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: from mx.blih.net (mx.blih.net [212.83.155.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "mx.blih.net", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 49BRV05hHgz3xCX; Tue, 28 Apr 2020 16:11:36 +0000 (UTC) (envelope-from manu@bidouilliste.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bidouilliste.com; s=mx; t=1588090294; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=E6h1d/yYoa/ryUyBIBDdmiF7DPMJHuWe0GrSBA9hfwg=; b=ZfIr2ve3k0sqab+lQC9qqTPqjmmvNS51qiAts1XoOXCxejBkmslU0MmAVisdrBb+L6FZ81 K62AZadGbsHGf59o8n1fbcg5AnoQOs5VgoMe9tzaqixqM8MWIz/CHeKci9eVl487K1KobH qte2SMhLz3M4ofQt33eQ2JEEtOmiSRY= Received: from skull.home.blih.net (lfbn-idf2-1-900-181.w86-238.abo.wanadoo.fr [86.238.131.181]) by mx.blih.net (OpenSMTPD) with ESMTPSA id a193bf94 (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO); Tue, 28 Apr 2020 16:11:34 +0000 (UTC) Date: Tue, 28 Apr 2020 18:11:31 +0200 From: Emmanuel Vadot To: Konstantin Belousov 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> X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.32; amd64-portbld-freebsd13.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 49BRV05hHgz3xCX X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bidouilliste.com header.s=mx header.b=ZfIr2ve3; dmarc=pass (policy=none) header.from=bidouilliste.com; spf=pass (mx1.freebsd.org: domain of manu@bidouilliste.com designates 212.83.155.74 as permitted sender) smtp.mailfrom=manu@bidouilliste.com X-Spamd-Result: default: False [-3.93 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_DKIM_ALLOW(-0.20)[bidouilliste.com:s=mx]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; R_SPF_ALLOW(-0.20)[+mx]; MV_CASE(0.50)[]; MIME_GOOD(-0.10)[text/plain]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; TO_DN_SOME(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[bidouilliste.com:+]; DMARC_POLICY_ALLOW(-0.50)[bidouilliste.com,none]; FREEMAIL_TO(0.00)[gmail.com]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; IP_SCORE(-1.43)[ip: (-9.38), ipnet: 212.83.128.0/19(1.80), asn: 12876(0.42), country: FR(0.00)]; ASN(0.00)[asn:12876, ipnet:212.83.128.0/19, country:FR]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] 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 16:11:38 -0000 On Tue, 28 Apr 2020 18:03:57 +0300 Konstantin Belousov 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