Re: Packet loss every 30.999 seconds

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 ?

Attachment: pgpkR5iv41tYI.pgp
Description: PGP signature

Relevant Pages

  • Re: Packet loss every 30.999 seconds
    ... The patch should work fine. ... the main problem is to figure out why PREEMPTION doesn't work. ... (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 ...
    (freebsd-stable)
  • Re: [patch] x86: fix taking DNA during 64bit sigreturn
    ... restore sigcontext is taking a DNA exception while restoring FP context from ... during the fxrstor in the sigreturn. ... Your patch looks good for now. ... the 64-bit code looks like it might have preemption issues too. ...
    (Linux-Kernel)
  • Re: 2.6.16-rt10
    ... Is anyone working on a port of this patch to the IA64 architecture? ... First issue: 'BUG: udev:45 task might have lost a preemption check!' ... MPT Fusion SCSI adapter. ... the MPT driver makes no use of these. ...
    (Linux-Kernel)
  • Re: RT and Cascade interrupts
    ... >>Yes later versions of the patch do. ... reentrance in __run_timerbut rather a preemption of it ... No explicit deletion attempt of the timer (synchronous or ... > other tk_action callback with a pending timer. ...
    (Linux-Kernel)
  • Re: Packet loss every 30.999 seconds
    ... The patch should work fine. ... It patches the bottom of the loop, which is only reached if the vnode ... So it will only help if there are thousands of dirty vnodes. ... the main problem is to figure out why PREEMPTION doesn't work. ...
    (freebsd-net)