Date: Wed, 5 Apr 95 15:00:51 MDT From: terry@cs.weber.edu (Terry Lambert) To: bde@zeta.org.au (Bruce Evans) Cc: paul@isl.cf.ac.uk, freebsd-hackers@FreeBSD.org, rgrimes@gndrsh.aac.dev.com, steve2@freefall.cdrom.com Subject: Re: Colorado Jumbo 250MB ft, and FreeBSD 2.0R Message-ID: <9504052100.AA01453@cs.weber.edu> In-Reply-To: <199504051941.FAA28922@godzilla.zeta.org.au> from "Bruce Evans" at Apr 6, 95 05:41:13 am
next in thread | previous in thread | raw e-mail | index | archive | help
> >That DELAY is hardware dependent is an inevitable side effect of > >the fact that it is not implemented using real timer code. > > It is implemented using real timer code. Read the code before > commenting. Oh, well, then the symptoms being reported aren't happening. 8-). I didn't realize real timer code had been implemented where a kernel thread switch occurrs and a timer event is scheduled instead of blocking the kernel thread that called DELAY until the time period has expired. Guess this means the kernel is real close to being SMP clean, since multiple threads executing in the kernel simultaneously is the main attribute of both SMP and a preemptible multithreaded kernel. I guess the only thing left is cache coherency for multiply accessed or common memory areas and interrupt delivery arbitration so that any processer can take the interrupt. Guess it also means that since the timer outcall is scheduled and the kernel continues executing, probe calls to long DELAY intervals are actually overlapped (as was recently suggested) and we no longer have to see the "waiting for devices to settle" on SCSI subprobes. This is cool. I suppose this real timer code is in the next snap? Unfortunately, I can't find it in the current one. I suppose these changes have also been documented for the maintainer of the ft so that the ft command can be integrated as a kernel thread? Oh, and with kernel threads available, I'd like to now suggest that the NFS and BIOD code be rewritten to take advantage of this significant advancement. Whoever is woring on the LFS should probably move the cleaner in as a kernel thread without a process context; this would definitely make it more responsive, as well as delaing with one of the two major impediments standing in the way of mounting multiple LFS partitions simultaneously. Oh, and if anyone wants to move AMD in as a kernel thread, I'm sure you would end up being a god for removing the visibile name space pollution the current user space implementation causes, not to mention the coresidency problems for multiple AMD instances. What? The real timer code and the necessary kernel support to make it usable isn't really there yet? Drat! That's what "real timer code" means. Terry Lambert terry@cs.weber.edu --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9504052100.AA01453>