lkml.org 
[lkml]   [1997]   [Apr]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Patches to speed up SLIP and PPP


On Sun, 27 Apr 1997, Alan Cox wrote:
> > In short, I'd much rather see a patch that
> > (a) gets rid of the "fast" vs "slow" interrupts. They used to make sense,
> > but they don't much do that any more. They only result in problems.
>
> You rejected one of those prior to 1.2 that came from the STRIP driver
> authors.

Yes. Note the "prior to 1.2". People have had patches like this floating
around for quite some time, but the timing has been bad. I think I
actually got a similar patch just before 2.0 too - and I'm definitely not
likely to change basic irq behaviour before making a stable release..

> As to the structure of it. I'd rather mark_bh() set the flag so the fast
> interrupt return wasnt taken. Or maybe mark_bh_nodefer()

mark_bh() already sets the flag that indicates we want to do the bh, it
makes no sense to have that set any other flag. If we wanted that we might
as well just always test bh_mask and bh_active.

What we want to have is to allow the interrupt handler to set the bottom
half bit, but _also_ say that "yes, I set the bit, but there is no
overwhelming reason to act on it immediately on return as I'm likely to
gather more data".

So if anything, we want to have "mark_bh_defer()", not nodefer. But the
act of delaying is really conceptually totally separate from the act of
marking the bottom half. Which is why I don't want to mix them.

Having the interrupt routine return a status word is really good, because
that can be used for other things too. If you look at the current irq.c
code for interrupt dispatch, you can see that we already _have_ the status
word, but the problem is that it is fixed (action->flags).

So instead of having this fixed status word, we'd have the irq handler
return the status it wants at run-time (the status word currently contains
information about whether it is a fast or slow interrupt, but also whether
we should use this interrupt for the randomizing stuff). Potentially we
can then add other dynamic flags.

Linus


\
 
 \ /
  Last update: 2005-03-22 13:39    [W:0.043 / U:1.316 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site