Date: Mon, 10 Apr 2017 01:11:25 -0700 (PDT) From: Chris Torek <torek@elf.torek.net> To: kostikbel@gmail.com Cc: ablacktshirt@gmail.com, ed@nuxi.nl, freebsd-hackers@freebsd.org, rysto32@gmail.com, vasanth.raonaik@gmail.com Subject: Re: Understanding the FreeBSD locking mechanism Message-ID: <201704100811.v3A8BP8B049595@elf.torek.net> In-Reply-To: <20170410071137.GH1788@kib.kiev.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
>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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201704100811.v3A8BP8B049595>