From owner-freebsd-hackers@freebsd.org Mon Apr 10 08:11:27 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 09B56D36128 for ; Mon, 10 Apr 2017 08:11:27 +0000 (UTC) (envelope-from torek@elf.torek.net) Received: from elf.torek.net (mail.torek.net [96.90.199.121]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "elf.torek.net", Issuer "elf.torek.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id CF1E0B19 for ; Mon, 10 Apr 2017 08:11:26 +0000 (UTC) (envelope-from torek@elf.torek.net) Received: from elf.torek.net (localhost [127.0.0.1]) by elf.torek.net (8.15.2/8.15.2) with ESMTPS id v3A8BP3c049596 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 10 Apr 2017 01:11:25 -0700 (PDT) (envelope-from torek@elf.torek.net) Received: (from torek@localhost) by elf.torek.net (8.15.2/8.15.2/Submit) id v3A8BP8B049595; Mon, 10 Apr 2017 01:11:25 -0700 (PDT) (envelope-from torek) Date: Mon, 10 Apr 2017 01:11:25 -0700 (PDT) From: Chris Torek Message-Id: <201704100811.v3A8BP8B049595@elf.torek.net> To: kostikbel@gmail.com Subject: Re: Understanding the FreeBSD locking mechanism Cc: ablacktshirt@gmail.com, ed@nuxi.nl, freebsd-hackers@freebsd.org, rysto32@gmail.com, vasanth.raonaik@gmail.com In-Reply-To: <20170410071137.GH1788@kib.kiev.ua> X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.6.2 (elf.torek.net [127.0.0.1]); Mon, 10 Apr 2017 01:11:25 -0700 (PDT) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Apr 2017 08:11:27 -0000 >Signal trampolines never were put on the kernel stack ... Oops, right, not sure why I was thinking that. However I would still prefer to have libc supply the trampoline address (the underlying signal system calls can do this, since until you are catching a signal in the first place, there is no need for a known-in-advance trampoline address). >Kstack still contains the remnants of the uarea, renamed to (per-thread) >pcb. There is no much sense in the split of struct thread vs. struct >pcb, but it is historically survived up to this moment, and clearing >things up requires too much MD work. >My opinion is that pcb on kstack indeed only eats the space and better be >put into td_md. That would be good. >> When an interrupt arrived, as long as it was not interrupting >> another interrupt, the system would get on a separate "interrupt >> stack" ... No, this is not a case, at least on x86. On VAX, and (emulated without hardware support) in my SPARC port, it was. :-) >There, 'normal' interrupts and exceptions reuse the current thread >kstack ... I never liked this very much, but if it's faster on x86, it's not unreasonable. And without hardware support (or if the TSS switch is too slow) it's OK. >> * In a "critical section", we wish to make sure that the current >> thread does not migrate from one CPU to another. >> ... we block interrupts for short durations here as well (actually >> when *leaving* the critical section, where we check to see if >> the scheduler would *like* us to migrate). >This is not true, both in explanation of intent, and in the implementation >details. Ah, and I see you added a compiler_membar and some comments here recently. I did indeed misread the micro-optimization. >You probably mixed critical_enter() and spinlock_enter() there. >The later indeed disables interrupt and intended to be used as part >of the spinlock (spin mutexes) implementation. What I meant was that it's a dreadful error to do, e.g.: critical_enter(); mtx_lock(mtx); ... mtx_unlock(mtx); critical_exit(); but the other order (lock first, then enter/exit) is OK. This is similar to the prohibition against obtaining a default mutex while holding a spin mutex. Chris