This is a stress test, it creates 4 processes and each process will do 1000
transfers using streams, so the trace is:
STRM_Issue -> WMD_CHNL_AddIOReq -> IO_Schedule
IO_Schedule schedules a call to IO_DPC using task let.
IO_DPC -> IO_DispatchChnl -> InputChnl -> CHNLSM_InterruptDSP2
Also IO_DispatchChnl -> OutputChnl -> CHNLSM_InterruptDSP2.
As we can call a lot CHNLSM_InterruptDSP2 in this test, there is a problem with
the timeout. However running other tests, videos and mp3 there no problems. I
think we should change to 10ms, only to make sure there is no problem when
CHNLSM_InterruptDSP2 is called a lot.
Let me know if you are agreed. Or have some comments about it.
Regards,
Fernando.
-----Original Message-----
From: Felipe Contreras [mailto:[email protected]]
Sent: Thursday, March 19, 2009 3:35 PM
To: Guzman Lugo, Fernando
Cc: [email protected]; Kanigeri, Hari; Hiroshi DOYU; Ameya Palande;
Felipe Contreras
Subject: Re: [PATCH B 3/3] tidspbridge: decreate timeout to a saner value
On Thu, Mar 19, 2009 at 11:19 PM, Guzman Lugo, Fernando <[email protected]> wrote:
>
> Yes, I applied this; in fact I have applied all the patches. If I increase
> the timeout there are no problems. The test I run creates 4 process and each
> one does several a lot of calls to InputChnl and OutputChnl, so I think this
> test is using the mailbox a lot and would be better a bigger timeout. What do
> you think?
How fast are these messages sent? Can you track down which functions
are calling CHNLSM_InterruptDSP2 and making these timeouts happen.
I think it's safe to leave the timeout at 10, but that means it's
possible the code will be busy-looping up to 10 ms which will increase
the CPU load. Somebody from Nokia (Siarhei?) suggested to idle-wait
for the mbox empty irq, I think that's the best way to implement this,
but at least for the use cases I'm interested in (video
encoding/decoding) timeouts don't seem to be an issue anymore.
--
Felipe Contreras
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
