From owner-cvs-all Wed Jun 27 1: 1:26 2001 Delivered-To: cvs-all@freebsd.org Received: from earth.backplane.com (earth-nat-cw.backplane.com [208.161.114.67]) by hub.freebsd.org (Postfix) with ESMTP id 0743037B406; Wed, 27 Jun 2001 01:01:20 -0700 (PDT) (envelope-from dillon@earth.backplane.com) Received: (from dillon@localhost) by earth.backplane.com (8.11.3/8.11.2) id f5R81Jk38018; Wed, 27 Jun 2001 01:01:19 -0700 (PDT) (envelope-from dillon) Date: Wed, 27 Jun 2001 01:01:19 -0700 (PDT) From: Matt Dillon Message-Id: <200106270801.f5R81Jk38018@earth.backplane.com> To: John Baldwin Cc: bmilekic@FreeBSD.org, jlemon@FreeBSD.org, cvs-all@FreeBSD.org, cvs-committers@FreeBSD.org, Mike Silbersack , "Brian F. Feldman" , Jonathan Lemon Alfred Perlstein Subject: Re: cvs commit: src/sys/netinet tcp_input.c tcp_output.c tcp_sub References: Sender: owner-cvs-all@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG :> 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 -- 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