On Saturday 10 August 2002 13:25, you wrote:
> On Sat, 10 Aug 2002, Robert Davies wrote:
> Trap levels are a hardware feature though, that said, I don't know what of
> the hardware features get used on SPARC Linux as I've not investigated.
Hardware trap vectors are common, it's one of the advantages of APICs, you
have fewer shared interrupt chains.
The problem is how much state you have to save on an interrupt, and what
compiler writers do when a subroutine is entered. In theory on SPARC you
don't need to save registers, as there's a 'sliding' window of available
registers. Unfortunately in practice due to limits on number of windows
(particularly in early SPARC), compilers just tended to save the whole state,
and not take advantage of the feature.
> > Anyway the ring buffer explanation, is best bit, the driver is only in
> > poll mode, whilst there is data to process, if there's none left in ring
> > buffer it goes back to interrupts. Whilst there is, then you don't need
> > interrupts to know there's something to do, do you?
>
> No, but you tell the device not to generate more and read data that needs
> processing - this is not polling per se. it's a hybrid situation - I guess
> it's similar to how a lot of serial/parallel stuff goes in theory,
> is this what you were alluding to before? I should read your link I guess.
The idea is a hybrid, but when interrupts are off it is polling, because it
is continually looking to consume data. The driver could not re-enable
interrupt on the NIC and use a short timer expiry to re-check, in which case
it is clearly polling.
If you can remember how we got into this it was due to 'the less interrupts
the better', and the disabling of interrupts and going into poll mode under
busy conditions certainly counts under that.
Rob
--------------------------------------------------------------------
http://www.lug.org.uk http://www.linuxportal.co.uk
http://www.linuxjob.co.uk http://www.linuxshop.co.uk
--------------------------------------------------------------------
This archive was generated by hypermail 2.1.3 : Sat 10 Aug 2002 - 16:42:37 BST