Date: Fri, 23 Nov 2001 18:31:42 -0800 From: Peter Wemm <peter@wemm.org> To: Luigi Rizzo <rizzo@aciri.org> Cc: Mike Smith <msmith@FreeBSD.ORG>, John Baldwin <jhb@FreeBSD.ORG>, current@FreeBSD.ORG Subject: Re: where is the idle_loop in current ? Message-ID: <20011124023142.9BB70380D@overcee.netplex.com.au> In-Reply-To: <20011123155916.C58238@iguana.aciri.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Luigi Rizzo wrote: > My understanding is that idle_loop threads _need_ to give up the cpu > because they are special: they must never be in a run queue, and the > scheduler knows about them (as a matter of fact, I cannot see where > in kern/kern_idle.c a priority is associated to these threads). No. In -current, the idle procs ***MUST***NOT*** do anything. If you want to do something at idle, you have to have an idle process/thread/whatever. This is how vm_zeroidle works. It is a process that is on the run queue. > But I really do not follow the "safer design" reasoning for > vm_zeroidle. It would be much safer not to depend on it to cooperate > in the scheduling and be subject to to the regular scheduling policy > (i.e. preempt when someone with higher priority becomes ready, > or when its quantum is over). Thats the problem.. We do *not* have preemption in -current right now. If it takes 10 seconds to zero all memory, the system will freeze for 10 seconds while vm_zeroidle runs, even if there is a higher priority process on the runqueue. Remember, context switches only happen at the user<->kernel boundary, or if the kernel portion blocks at a defined sleep point. In -current we allow interrupt threads to preempt on i386 only. > cheers > luigi > > On Fri, Nov 23, 2001 at 03:32:46PM -0800, Mike Smith wrote: > > > In order to port my network polling stuff to current, I was looking > > > at ways to do things within the "idle loop", and was pointed to > ... > > You should just schedule a thread with priority equal to or just above > > that of the idle thread. > > > > > I do not follow, however, the reason why these two threads periodically > > > give up the CPU, given that their priority is (i guess) lower than > ... > > > Spinning forever in a thread is always a bad idea; you can't be assured > > that you will always be preempted. The idle thread calls the scheduler > > periodically for just this reason; it's a safer design. > > Still i do not > > -- > > ... every activity meets with opposition, everyone who acts has his > > rivals and unfortunately opponents also. But not because people want > > to be opponents, rather because the tasks and relationships force > > people to take different points of view. [Dr. Fritz Todt] > > V I C T O R Y N O T V E N G E A N C E > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-current" in the body of the message > > Cheers, -Peter -- Peter Wemm - peter@FreeBSD.org; peter@yahoo-inc.com; peter@netplex.com.au "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20011124023142.9BB70380D>