Messages in this thread | | | Date | Fri, 7 May 1999 01:09:19 -0700 | From | <> | Subject | Re: 2.2.x run_bottom_halves bug |
| |
Date: Thu, 6 May 1999 15:28:04 -0400 (EDT) From: "Benjamin C.R. LaHaise" <blah@kvack.org>
I've been testing drivers ported from 2.0 to 2.2 and I'm noticing that bottom halves are occasionally getting delayed until the next interrupt, which usually turns out to be the timer going off, adding an unnecessary 10-20ms delay. The case I've encountered this with is when a bottom half handler triggers another bottom half in my driver's packet reassemble code.
This was under discussion recently, and you simply cannot safely do what your patch is trying to do.
For example, when should your loop exit? How do you handle starvation cases (watch what a few parallel ping floods do to the machine over 100baseT with your change applied). You will pin the cpu in BH processing. If the cpu is slow enough, or it has enough work to do over and over, it may never come out. See?
The consensus is that most of us do agree that we do want to relook at the bits again for several cases, but certainly not endlessly.
You have to put some kind of heuristic cork into the scheme or else you end up with huge problems.
Later, David S. Miller davem@redhat.com
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |