Date: Wed, 19 Dec 2007 22:47:12 +0200 From: Kostik Belousov <kostikbel@gmail.com> To: Julian Elischer <julian@elischer.org> Cc: freebsd-net@freebsd.org, freebsd-stable@freebsd.org, David G Lawrence <dg@dglawrence.com> Subject: Re: Packet loss every 30.999 seconds Message-ID: <20071219204712.GE57756@deviant.kiev.zoral.com.ua> In-Reply-To: <47697480.9070208@elischer.org> References: <20071218233644.U756@besplex.bde.org> <20071218141742.GS25053@tnn.dglawrence.com> <20071219022102.I34422@delplex.bde.org> <20071218165732.GV25053@tnn.dglawrence.com> <20071218181023.GW25053@tnn.dglawrence.com> <20071219235444.K928@besplex.bde.org> <20071219151926.GA25053@tnn.dglawrence.com> <20071220032223.V38101@delplex.bde.org> <20071219170434.GG25053@tnn.dglawrence.com> <47697480.9070208@elischer.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--ffoCPvUAPMgSXi6H Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Dec 19, 2007 at 11:44:00AM -0800, Julian Elischer wrote: > David G Lawrence wrote: > >>> In any case, it appears that my patch is a no-op, at least for the > >>>problem I was trying to solve. This has me confused, however, because = at > >>>one point the problem was mitigated with it. The patch has gone through > >>>several iterations, however, and it could be that it was made to the t= op > >>>of the loop, before any of the checks, in a previous version. Hmmm. > >>The patch should work fine. IIRC, it yields voluntarily so that other > >>things can run. I committed a similar hack for uiomove(). It was > > > > It patches the bottom of the loop, which is only reached if the vnode > >is dirty. So it will only help if there are thousands of dirty vnodes. > >While that condition can certainly happen, it isn't the case that I'm > >particularly interested in. > > > >>CPUs, everything except interrupts has to wait for these syscalls. Now > >>the main problem is to figure out why PREEMPTION doesn't work. I'm > >>not working on this directly since I'm running ~5.2 where nearly-full > >>kernel preemption doesn't work due to Giant locking. > > > > I don't understand how PREEMPTION is supposed to work (I mean > >to any significant detail), so I can't really comment on that. >=20 > It's really very simple. >=20 > When you do a "wakeup"=20 > (or anything else that puts a thread on a run queue) > i.e. use setrunqueue() > then if that thread has more priority than you do, (and in the general ca= se > is an interrupt thread), you immedialty call mi_switch so that it runs=20 > imediatly. > You get guaranteed to run again when it finishes.=20 > (you are not just put back on the run queue at the end). As far as I see it, only the interrupt threads can put the kernel thread off the CPU. More, the thread being forced out shall be an "idle user thread". See kern_switch.c, maybe_preempt(), the #ifndef FULL_PREEMPTION block. >=20 > the critical_enter()/critical_exit() calls disable this from happening to= =20 > you if you really must not be interrupted by another thread. >=20 > there is an option where it is not jsut interrupt threads that can jump i= n, > but I think it's usually disabled. Do you mean FULL_PREEMPTION ? --ffoCPvUAPMgSXi6H Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFHaYNPC3+MBN1Mb4gRAs3VAKCAuYRei7c6tM7PCglA0MhS1wv9YgCg2qQD rtEKhVPITTealtAh8v2AClM= =as0Z -----END PGP SIGNATURE----- --ffoCPvUAPMgSXi6H--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20071219204712.GE57756>