Date: Wed, 27 Jun 2001 08:37:18 -0700 (PDT) From: Matt Dillon <dillon@earth.backplane.com> To: John Baldwin <jhb@FreeBSD.org> Cc: Jonathan Lemon Alfred Perlstein <bright@sneakerz.org>, "Brian F. Feldman" <green@FreeBSD.org>, Mike Silbersack <silby@FreeBSD.org>, cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org, jlemon@FreeBSD.org, bmilekic@FreeBSD.org Subject: Re: cvs commit: src/sys/netinet tcp_input.c tcp_output.c tcp_sub Message-ID: <200106271537.f5RFbIQ40573@earth.backplane.com> References: <XFMail.010627082529.jhb@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
:Hmm. So you like interrupt preemption. Gee, that happens to be all the :preemption we actually _do_. (Well, when a mutex is released, if a higher :priority thread is blocked on that mutex, we will preempt the thread that :released the mutex.) However, we don't do preemption just because a higher :priority thread shows up. However, it is the interrupt preemption that means :that a kthread can switch CPU's, since when we switch to the ithread, the :current process is still runnable and gets put on the runqueue. One :optimization that might be useful at some point for SMP systems would be to :release the sched_lock in ithread_schedule for a bit to give an AP a chance to :grab the ithread and run it and then not do a switch if that does happen so we :can avoid having to preempt the current thread if their is an idle CPU that can :run the ithread. : :-- : :John Baldwin <jhb@FreeBSD.org> -- http://www.FreeBSD.org/~jhb/ I think you are missing the point, John. The ability to cause a thread to magically switch from one cpu to another, or to allow some other non-interrupt thread to get that cpu as a side effect of the interrupt occuring, is not a minor side effect. It's a major problem that basically fucks up any chance whatsoever of writing efficient, high performance SMP code in FreeBSD. It prevents anyone coding up kernel threads from being able to make the most basic assumptions about the state of the machine, about the state of the per-cpu area... pretty much about the state of *anything*! It is pure insanity to even consider that it might be a good thing. The BSDI code very specifically avoided the problem (gee, take one guess why!) simply by ensuring that the interrupt thread preemption would be equivalent from the coding point of view of a normal thread to a normal interrupt in, say, 4.2. The normal thread would be guarenteed that the interrupt thread preempting it would (A) not block from the stand point of the normal thread (it gets scheduled instead and the normal thread is resumed), and (B) would guarentee that the normal thread would resume on completion. Not some other random thread, not on a different cpu... the original thread would resume on the same cpu. This is why BSDI implemented interrupt preemption as a special case, and while I was not overly fond of it when it was discussed at the Yahoo meeting, it was an order of magnitude *better* then what is in -current now! -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200106271537.f5RFbIQ40573>