Packet loss every 30.999 seconds

[Kostik Belousov]

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 top
> >>>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.
> 
> It's really very simple.
> 
> When you do a "wakeup" 
> (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 case
> is an interrupt thread), you immedialty call mi_switch so that it runs 
> imediatly.
> You get guaranteed to run again when it finishes. 
> (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.
> 
> the critical_enter()/critical_exit() calls disable this from happening to 
> you if you really must not be interrupted by another thread.
> 
> there is an option where it is not jsut interrupt threads that can jump in,
> but I think it's usually disabled.
Do you mean FULL_PREEMPTION ?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-net/attachments/20071219/082c0924/attachment.pgp