Date: Wed, 27 Jun 2001 08:25:29 -0700 (PDT) From: John Baldwin <jhb@FreeBSD.org> To: Matt Dillon <dillon@earth.backplane.com> 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: <XFMail.010627082529.jhb@FreeBSD.org> In-Reply-To: <200106270801.f5R81Jk38018@earth.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 27-Jun-01 Matt Dillon wrote: > >:> at it closely. idle_proc() cannot ever block though I suppose it could >:> be interrupted and switched out preemptively. >: >:It can't obtain a sleep lock at all (either via lock or trylock) because if >:another thread blocks on that lock, the priority propagation code will put >:the >:idle process on the runqueue, at which point you can end up running cpu A's >:idle process on both cpu A and cpu B at the same time. Given that curproc is >:the uniquifier for locks, the result could best be described as "all hell >:breaking loose". > > That sounds like a bug in the priority logic... and sounds like > something that would be easy to fix. An idle proc should never be put > on the general run queue by anyone for any reason. The priority logic > could be allowed to safely preempt it, but should never, ever try to > schedule it. I would even argue that the priority logic shouldn't even > bother trying to preempt an idleproc - simply schedule the interrupt > and the idleproc will switch to it much faster then preemption ever > could. Since an idleproc does not mess with the run queue, and > assuming FreeBSD-SMP ever moves to a per-cpu run queue, the interrupt > code would be able to schedule the interrupt thread to the current cpu > without having to gain a single mutex if the currently running proc is > the idle proc. It wouldn't be that hard to implement, but why complicate the priority propagation code further? It is easier to just avoid the problem to begin with. >:The future of page zering is that it will be pushed off into a low-priority >:worker thread that is woken up when there are enough pages to make zeoring >:worthwhile and goes back to sleep when there are no longer enough pages to >:make >:zeoring worthwhile. >: >:-- >: >:John Baldwin <jhb@FreeBSD.org> -- http://www.FreeBSD.org/~jhb/ > > I suppose you could do it that way, but using worker threads is a > rather sophisticated solution. You would need a worker thread wired > to each cpu to get a similar level of performance and to avoid L1 and L2 > cache thrashing. Sounds nasty to me. It's during idle time. Do you really want to optimize the idle loop? If we are idle, we are idle. It probably will require per-cpu worker threads however. > I know you guys are in love with this kernel preemption stuff, but I have > yet to see any believable argument that it actually improves performance > and I see plenty that makes me believe it does the opposite. The BSDI > interrupt-preemption solution made sense. The general preemption being > worked on in -current makes no sense. At all. For example, the idea > that a kernel thread can be switched to a different cpu *while* it is > running is simply insane! The CPU caches are completely destroyed, > the cache coherency protocol is mangled, there is no way to access > per-cpu structures without holding mutexes, or even the ability to > cache a pointer into the per-cpu area, etc etc etc... unbelievable. 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. > -Matt -- John Baldwin <jhb@FreeBSD.org> -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ 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?XFMail.010627082529.jhb>