6.2 SHOWSTOPPER - em completely unusable on 6.2
Scott Long
scottl at samsco.org
Wed Sep 27 12:30:46 PDT 2006
Peter Jeremy wrote:
> On Wed, 2006-Sep-27 10:32:49 -0600, Scott Long wrote:
>
>>My theory here is that something in the kernel, likely VM/VFS, is
>>holding the Giant lock for an inordinate amount of time.
>
>
> In the past (RELENG_5) I've had major problems with syncer delaying
> interrupt threads for long periods (I've seen 8msec). See
> http://lists.freebsd.org/pipermail/freebsd-stable/2005-February/012346.html
> I'm not sure if this is still a problem (but I am still having some
> problems which may be caused by excessive interrupt and will be doing
> some debugging as I get time).
>
>
>>I have a few ideas on tracking down the root cause, but they are pretty
>>pretty painful and slow.
>
>
> In my case, I was fairly certain that the problem I was seeing was
> excessive interrupt latency for my driver. The approach I took was to
> capture TSC, IRQ number and curproc address in lapic_handle_intr(),
> atpic_handle_intr() and at the beginning of my interrupt handler into
> a ring buffer. I'd dump the ring buffer into a file using a userland
> tool and then post-process the file looking for oddities. In my case,
> there was a _very_ high correlation between long latencies and syncer.
> If anyone's interested in this approach, I can provide the relevant
> code diffs.
>
Yes, I was thinking about the syncer too, but the timeouts for ethernet
interfaces are measured in seconds, not milliseconds.
>
>>2. Add INTR_FAST shims to the usb and ichsmb drivers so that neither
>>uses an ithread.
>
>
> The problem I ran into with this approach was that my interrupt
> handler needs to use psignal(9) - which requires PROC_LOCK() which
> (AFAIK) isn't allowed in an INTR_FAST handler.
You can define a very simple INTR_FAST handler that just disables the
interrupt at the device and then schedules a taskqueue to do the real
work. This is what I did for if_em, actually.
>
> It would be useful if our interrupt subsystem allowed both INTR_FAST
> and normal interrupt handlers to be defined. If an INTR_FAST handler
> is defined then it gets executed and defines whether its associated
> interrupt thread handler needs to be triggered. If there's no
> INTR_FAST handler then the interrupt thread is always triggered.
>
This was an SoC2006 project, and I believe it will be committed fairly soon.
Scott
More information about the freebsd-stable
mailing list