Re: bottom half
On Fri, Jun 19, 2015 at 08:06:37AM -0400, Greg Troxel wrote: Overall, the whole subject of locking in the kernel is too hard for new people to figure out, and I think it's great that Kamil is writing an overview for it. Indeed, e.g., my first stab at looking at vnd http://mail-index.netbsd.org/tech-kern/2015/05/22/msg018746.html Since then, I came across Solaris Internals, and a sun microsystems Writing Device Drivers, which I wish I had seen earlier - they seem to be closer to what is currently in NetBSD than the 4.4 red book. e.g. page 82, code example 4-2 of writing device drivers seems to be exactly what vndlock() should look like. Cheers, Patrick
Re: bottom half
On Fri 19 Jun 2015 at 11:45:40 +0200, Edgar Fuß wrote: To eleborate, as I seem to have been too cryptic in my references: I learned the terms top and bottom half from The Design and Implementation of the 4.4BSD Operating System by McKusick, Bostic, Karels and Quaterman. The text on page 51 explains The bottom half of the kernel comprises routines that are invoked to handle hardware interrupts. and the figure 3.1 above explains Never scheduled, cannot block. Runs on kernel stack in kernel address space. For reference: - the same book with 4.3 in the title has the same Figure 3.1, but on page 44. - the same book with FreeBSD in the title has the same Figure 3.1, also on page 51. -Olaf. -- ___ Olaf 'Rhialto' Seibert -- The Doctor: No, 'eureka' is Greek for \X/ rhialto/at/xs4all.nl-- 'this bath is too hot.' pgpLPiDZFVRHO.pgp Description: PGP signature
Re: bottom half
Because of this transition from halves to thirds, OK, I understand. and because of []confusion with Linux, Sigh. the term bottom half may now be best avoided. OK. it's great that Kamil is writing an overview for it. YES.
Re: bottom half
On 2015-06-19 14:27, Edgar Fuß wrote: as the Linux bottom halves do not handle the hardware interrupt itself, and they can be interrupted by anything. Oh well. So they use a well-established terminology to meen something different from what it originally meant. Sigh. Thanks for the explanation. Hey. It is Linux. What did you expect? :-) Johnny -- Johnny Billquist || I'm on a bus || on a psychedelic trip email: b...@softjar.se || Reading murder books pdp is alive! || tryin' to stay hip - B. Idol
Re: bottom half
On 2015-06-19 11:45, Edgar Fuß wrote: Runs on kernel stack in kernel space is not the same thing as the Linux concept of bottom half. :-) I don't know what the Linux (or VMS or Windows) concept of nottom half is. I thought I knew what the BSD concept of kernel halves is. I can't comment on Windows - I have no idea. VMS uses a very different solution, so it don't make much sense to talk about that here (or at least the parts that I know, which might be outdated). If I remember Linux right, they have a fixed list of registered bottom half handlers (which of course ran out of space a long time ago), and then through some tricks extended it to be more general, but in essence the bottom half is the part of the device driver that runs after an interrupt to complete an I/O request. The top half being also running in the kernel, but in the context of a process that does the I/O, and the top half blocks until the I/O completes. And the bottom half is the part the unblocks the top half again. And each driver has its own bottom and top halves. One major point of the bottom halves is that when running the bottom half, interrupts are not blocked. A device driver normally do only a minimal amount of work in the interrupt handler itself, and then defer the rest of the work to the bottom half code, which will run at some later time. Of course, I could be remembering this all wrong, and it might be outdated as well. So take what I write with a grain of salt. Or rather, read up on it in a Linux book instead. I would say the bottom half concept in Linux is close to the softint stuff in NetBSD. But I might be wrong on that one, as I don't remember all the details of that either right now. And tghe text you refer to in the 4.4BSD book then obviously are not describing the same concept as the Linux bottom halves, as the Linux bottom halves do not handle the hardware interrupt itself, and they can be interrupted by anything. Johnny -- Johnny Billquist || I'm on a bus || on a psychedelic trip email: b...@softjar.se || Reading murder books pdp is alive! || tryin' to stay hip - B. Idol
Re: bottom half
as the Linux bottom halves do not handle the hardware interrupt itself, and they can be interrupted by anything. Oh well. So they use a well-established terminology to meen something different from what it originally meant. Sigh. Thanks for the explanation.
Re: bottom half
Runs on kernel stack in kernel space is not the same thing as the Linux concept of bottom half. :-) I don't know what the Linux (or VMS or Windows) concept of nottom half is. I thought I knew what the BSD concept of kernel halves is. I don't know what the figured referred to is, Figure 3.1 Run-time structure of the kernel but the text quoted do not say bottom half at least... The text describes what bottom half of the kernel in the figure means. To eleborate, as I seem to have been too cryptic in my references: I learned the terms top and bottom half from The Design and Implementation of the 4.4BSD Operating System by McKusick, Bostic, Karels and Quaterman. The text on page 51 explains The bottom half of the kernel comprises routines that are invoked to handle hardware interrupts. and the figure 3.1 above explains Never scheduled, cannot block. Runs on kernel stack in kernel address space. Now it may well be that things have changed, my understanding is out-dated and NetBSD handles interrupts in a conceptually different way from 4.4BSD. But if things have not changed, I think a documentation on NetBSD's locking mechanisms (thanks go to Kamil for writing this!) may well use the terms the definite reference on 4.4BSD uses, no matter what penguin addicts use the term for. In fact I think it should because I can't stand people picking up well-established terms, re-defining them and then refusing to accept the traditional definition. Ever tried to talk to someone grown up with git about what a patch is?
Re: bottom half
Taylor R Campbell campb...@mumble.net writes: What I meant when I said that to Kamil is that we don't have any formalized notion called `top half' and `bottom half'. We have hard interrupt handlers which are supposed to have small bounded latency, and we have soft interrupt handlers and kernel threads at lower priorities to which hard interrupt handlers defer long computations and I/O. The notion of top and bottom half is historical in BSD from long ago (2BSD even). As far as formal goes, I think it's just the usual BSD problem of an undocumented design. Since the original, two things have happened: we need locking, because preemption of interrupts only works for mutual exclusion on a single CPU we have softints, which are not bottom half and not top half, but in between. This is not really because they are preemptible (traditional disk interrupt handlers were preemptible by serial drivers) but because they can sleep. Because of this transition from halves to thirds, and because of cconfusion with Linux, the term bottom half may now be best avoided. Overall, the whole subject of locking in the kernel is too hard for new people to figure out, and I think it's great that Kamil is writing an overview for it. pgpcNNHlwyns_.pgp Description: PGP signature
Re: bottom half
On Fri, 19 Jun 2015, Johnny Billquist wrote: On 2015-06-19 11:45, Edgar Fu?? wrote: Runs on kernel stack in kernel space is not the same thing as the Linux concept of bottom half. :-) I don't know what the Linux (or VMS or Windows) concept of nottom half is. I thought I knew what the BSD concept of kernel halves is. I can't comment on Windows - I have no idea. VMS uses a very different solution, so it don't make much sense to talk about that here (or at least the parts that I know, which might be outdated). If I remember Linux right, they have a fixed list of registered bottom half handlers (which of course ran out of space a long time ago), and then through some tricks extended it to be more general, but in essence the bottom half is the part of the device driver that runs after an interrupt to complete an I/O request. The top half being also running in the kernel, but in the context of a process that does the I/O, and the top half blocks until the I/O completes. And the bottom half is the part the unblocks the top half again. And each driver has its own bottom and top halves. One major point of the bottom halves is that when running the bottom half, interrupts are not blocked. A device driver normally do only a minimal amount of work in the interrupt handler itself, and then defer the rest of the work to the bottom half code, which will run at some later time. Of course, I could be remembering this all wrong, and it might be outdated as well. So take what I write with a grain of salt. Or rather, read up on it in a Linux book instead. I would say the bottom half concept in Linux is close to the softint stuff in NetBSD. But I might be wrong on that one, as I don't remember all the details of that either right now. From what I remember the BSD book talks about the top half and bottom half of the driver, not just interrupt dispatch the way linux does. On linux, the top half of the interrupt handler runs in interrupt context, either preempting a kernel thread on the kernel stack or on a separate interrupt stack depending on the particular architecture. The bottom half of an interrupt handler is basically a softint that runs on a kernel stack. In general, you register a top half handler to acknowledge the interrupt. If the interrupt has any notable amount of processing to do or needs to fiddle with locks, the top half schedules a bottom half interrupt to do that. In addition to that you can have code that runs in a kernel thread, and you can have code that runs in the kernel in process context as the result of a system call. It's been a while since I fiddled with interrupts on NetBSD, but ISTR we now schedule an interrupt thread to do all of the processing so there is no equivalent of the linux interrupt top half and interrupt bottom half. Or is that Solaris? I forget. Eduardo
Re: bottom half (was: New manpage: locking(9))
On Thu, Jun 18, 2015 at 11:14:09PM +0200, Edgar Fu? wrote: 1. I was told that kernel halves are not used in NetBSD. I don't get that. Does NetBSD handle interrupts in a way totally different from BSD? bottom halves in the sense used are a linux thing. -- David A. Holland dholl...@netbsd.org
Re: bottom half (was: New manpage: locking(9))
Date: Thu, 18 Jun 2015 23:14:09 +0200 From: Edgar Fuss e...@math.uni-bonn.de 1. I was told that kernel halves are not used in NetBSD. I don't get that. Does NetBSD handle interrupts in a way totally different from BSD? What I meant when I said that to Kamil is that we don't have any formalized notion called `top half' and `bottom half'. We have hard interrupt handlers which are supposed to have small bounded latency, and we have soft interrupt handlers and kernel threads at lower priorities to which hard interrupt handlers defer long computations and I/O.
Re: bottom half
bottom halves in the sense used are a linux thing. Hugh? I learned the term from a red book with a daemon on the cover. I very much doubt the four authors are writing about linux given the book's title. The figure says Never scheduled, cannot block. Runs on kernel stack in kernel address space. Is this outdated?
Re: bottom half
On 2015-06-18 23:23, Edgar Fuß wrote: bottom halves in the sense used are a linux thing. Hugh? I learned the term from a red book with a daemon on the cover. I very much doubt the four authors are writing about linux given the book's title. The figure says Never scheduled, cannot block. Runs on kernel stack in kernel address space. Is this outdated? Runs on kernel stack in kernel space is not the same thing as the Linux concept of bottom half. :-) That said, I don't know what the figured referred to is, but the text quoted do not say bottom half at least... Johnny -- Johnny Billquist || I'm on a bus || on a psychedelic trip email: b...@softjar.se || Reading murder books pdp is alive! || tryin' to stay hip - B. Idol
