On Sunday 01 April 2001  4:44 pm, IWAMOTO Toshihiro wrote:
> At Sun, 1 Apr 2001 15:48:48 +0100,
>
> Chris Gilbert wrote:
> > I've been looking over the irq handling code with a view to speeding it
> > up (although measuring performance isn't very easy)  Anyway I've tweaked
> > the code, got rid of the excessive looping when looking at the irq
> > request field and which bit's are set (it checked every bit) and replaced
> > it with ffs like code.  I've also shifted the ldr's around to try and get
> > rid of load delays causing pipeline stalls.
> >
> > I've attached the patch.  If people could take a look and check I've not
> > done anything really daft (it runs, I'm currently doing a make build with
> > it in place :) (or if there's anything else I can do :)  If it looks ok
> > I'll commit it.
> >
> > Does anyone know a good way to test the irq handling speed?
>
> Does it make sense to run a userland benchmark program to measure
> irq_entry speed?

I was wondering if some kind of heavy disk read/write etc might exercise irq 
handling, but then you might find that it gets hidden by the vm system...

> Although this kind of test cannot predict performance penalty from
> cache misses of irq_ffs_table, I suppose it would be somewhat useful.

true, however I'd hope that the removal of the checking of every bit in the 
irq request value would hide any issue like that. (and the ffs table is only 
64 bytes big, which is 2 cache lines on the SA)

> (I hope this patch is also useful on hpcarm, but cache miss penalty is
> quite high there, at least for my jornada720.  lmbench says it takes
> 300ns to load a cache line...)

It should be useable elsewhere, but I've not investigated the irq handling on 
other systems yet.  I've only got access to a riscpc, but I do believe that 
the core code will be similiar.

Cheers,
Chris