Date: Wed, 27 Jun 2001 01:01:19 -0700 (PDT) From: Matt Dillon <dillon@earth.backplane.com> To: John Baldwin <jhb@FreeBSD.org> Cc: bmilekic@FreeBSD.org, jlemon@FreeBSD.org, cvs-all@FreeBSD.org, cvs-committers@FreeBSD.org, Mike Silbersack <silby@FreeBSD.org>, "Brian F. Feldman" <green@FreeBSD.org>, Jonathan Lemon Alfred Perlstein <bright@sneakerz.org> Subject: Re: cvs commit: src/sys/netinet tcp_input.c tcp_output.c tcp_sub Message-ID: <200106270801.f5R81Jk38018@earth.backplane.com> References: <XFMail.010626214548.jhb@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
:> 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.
: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.
With very little work the existing idleprocs can handle the
page-zeroing/malloc-zeroing operations now and then be adapted to the
per-cpu memory stuff that is the obvious goal of the people working
on the memory subsystem. All without the overhead of a full-boat
scheduled thread - no wakeup or sleep ops involved, no sophisticated
thread handling. No preemption capability is necessary (though an 'abort'
hint would be useful), and there are some fairly standard 'idle process
tricks' that can be used to reduce switching latency by a factor
of 2 or 3 over a normal kernel thread. For example, with very
little effort an idle process could simply trampoline in with a minimal
register load and can switch away with NO register save at all. I didn't
implement it that way because I didn't want to make the Alpha guys
job harder, but I left the door open.
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.
-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?200106270801.f5R81Jk38018>