Date: Sun, 25 Nov 2001 15:51:22 -0800 From: Peter Wemm <peter@wemm.org> To: Luigi Rizzo <rizzo@aciri.org> Cc: Bruce Evans <bde@zeta.org.au>, Mike Smith <msmith@FreeBSD.ORG>, John Baldwin <jhb@FreeBSD.ORG>, current@FreeBSD.ORG Subject: Re: where is the idle_loop in current ? Message-ID: <20011125235122.0FD1238CC@overcee.netplex.com.au> In-Reply-To: <20011125064458.A76206@iguana.aciri.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Luigi Rizzo wrote: > Now, the whole problem here seems to be that kernel threads > are not preemptable, which is something that worries me a > bit because in CURRENT we use them for interrupt handlers as > well, and those used to be preemptable (subject to spl masks) > in RELENG_4. No, the kernel in general isn't preemptable in that a higher priority process that becomes runnable will not run until the lower priority process either blocks, returns to userland, or yields the cpu. Interrupt threads are special in that they will preempt a process that is in kernel context. This is not the same as a higher priority process being woken up with wakeup(). The problems in vm_zeroidle come from trying to avoid changing both the mechanism and the work algorithm at the same time. The mechanism got switched over, and now it is time to fix the algorithms to deal with that. Bruce has written about this elsewhere. Interrupts still preempt just like on releng_4, but subject to the &Giant. Obviously this means that a non-mpsafe interrupt cannot do anything useful if it interrupts non-mpsafe code as it will immediately block on &Giant. Audio is an example of something that *is* mpsafe though and can preempt just about anything in the kernel, even on another CPU. The idle processes are special in -current. What I said about them not being able to do anything isn't quite correct. The restriction is that they cannot, and must not, block. This means they cannot tsleep or get a mutex. And since they run outside Giant, that means they cannot go anywhere near the non-mpsafe parts of the kernel, such as the network stack or drivers. That means, unfortunately, that you have no choice in -current. It has to be and idle priority process. A side effect of that means that there is no longer a reason that it cannot be machine independent and SMP safe. > On the other hand, if preemptable threads are implemented > (which one of the messages in this thread suggests might > occur), then things will improve even wrt RELENG_4 It simplifies things a lot. It means that the ugly hacks to yield the cpu in things like vm_pagezero can go away entirely. It makes life a lot easier for people wanting to do idle priority work. > On Sun, Nov 25, 2001 at 09:26:51PM +1100, Bruce Evans wrote: > > > Anyway, I think luigi wants the non-process benefits of hacking on the > > old idle loop. Sorry, the only way to get these seems to be to upgrade > > to RELENG_4. > > which, funnily, I have already... This thread came out because in > order to import my polling stuff in the tree (see my yet-unanswered > request to -core), having a CURRENT version seems useful to lower > resistance. Because we haven't seen the cleaned up, -current version yet. We told you before that we had issues with the style bugs etc. We cant give you a blanket commit approval without seeing it first. > I don't mind having spent the time for doing it, in the process i > certainly learned something on the internals of CURRENT, but this > seems to be about the only useful result of this additional work :) > > cheers > luigi > ----------------------------------+----------------------------------------- > Luigi RIZZO, luigi@iet.unipi.it . ACIRI/ICSI (on leave from Univ. di Pisa) > http://www.iet.unipi.it/~luigi/ . 1947 Center St, Berkeley CA 94704 > Phone: (510) 666 2927 > ----------------------------------+----------------------------------------- > > 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?20011125235122.0FD1238CC>