Syslink Notify latency in Linux

Lajos Rancz

Expert 1065 points

Other Parts Discussed in Thread: SYSBIOS

Hi all,

In a sample application on DM8148 I do the following:

The HDVPSS M3 notifies the Cortex A8 (Linux) and the C674x DSP (sysbios) (with ID 11)
Both the A8 and DSP pend on a semaphore, which is posted by the HDVPSS Notification callback
Then the A8 pends on an other semaphore which is posted by an other Notification (ID: 12) callback
After the DSP receives the notification from HDVPSS M3 (semaphore_pend is returns) sends an other notification (ID: 12) to the A8
On A8 side I measure the amount of time (T) of pending on Semaphore2.
Goto step 1

The measured time T is about 5 ms in each cycle. I guess it is too much. What could be the problem?

Regards,
Lajos

over 11 years ago

0 janet over 11 years ago

TI__Mastermind 22760 points

Hi Lajos,

Could you check the DSP clock rate? Maybe it is running very slowly. You could also put a printk of the timestamp in the callback on the A8 side that is posted by the interrupt. This callback is the function _Dm8168IpcInt_isr(), in the file:

ti/syslink/ipc/hlos/knl/notifyDrivers/arch/ti81xx/Dm8168IpcInt.c

Then you could measure the time from when the isr was posted to when the thread became unblocked on Semaphore2. That would tell you if the delay was occurring on the A8.

Best regards,

Janet

0 Lajos Rancz over 11 years ago in reply to janet

Expert 1065 points

Hi Janet,

The DSP clock rate is OK, I've verified it. I did that you supposed in the following way (red is mine code):

#include <linux/time.h>

unsigned long volatile start;
unsigned long volatile dsp;

static
Bool
_Dm8168IpcInt_isr (Ptr ref)
{
...
if (Dm8168IpcInt_state.isrObjects [i].fxn != NULL) {
int msg_id = *(int*)(*(int*)Dm8168IpcInt_state.isrObjects [i].fxnArgs);

  struct timeval tv;
  do_gettimeofday(&tv);
  unsigned long now;
  now = tv.tv_usec + tv.tv_sec * 1000000;
  switch (msg_id)
  {
  case 13: // Notify from HDVPSS M3
      start = now;
      break;
  case 16: // Notify from DSP M3
      dsp = now;
      printk(KERN_INFO "Total: %d\n", dsp-start);
      break;
  default:
break;
}
Dm8168IpcInt_state.isrObjects [i].fxn (Dm8168IpcInt_state.isrObjects [i].fxnArgs);
}

The measurement show the total time is about 5 ms, as in user space. So, the malfunction must be in kernel space I think. What could be the next step?

Regards,
Lajos

0 Lajos Rancz over 11 years ago in reply to Lajos Rancz

Expert 1065 points

Hi Janet,

I withdraw my statement! It seems that the latency is in DSP side, exactly in the Cache_inv function call. It invalidates about a half MB memory area. How could it be so slow?

Regards,
Lajos

0 Robert Tivy over 11 years ago in reply to Lajos Rancz

TI__Mastermind 18260 points

Hi Lajos,

I'm filling in for Janet while she's OOO, so I'll try to keep this thread moving until she gets back...

Cache invalidating does take some significant time. Could you tell us which function is doing this large Cache_inv()?

Regards,

- Rob

0 Lajos Rancz over 11 years ago in reply to Robert Tivy

Expert 1065 points

Hi Rob,

It is in our code, not in the syslink! Nevertheless, where can I find benchmarks about cache operations?

Thanks,
Lajos

0 janet over 11 years ago in reply to Lajos Rancz

TI__Mastermind 22760 points

Hi Lajos,

We don't have any published benchmarks for cache operations. I'm attaching a BIOS test that measures the Cache_inv() times for different buffer sizes, that you can use to measure times for your platform.

Note that you can read the TSCL register instead of calling Timestamp_get32(). That would eliminate the overhead of the call to Timestamp_get32().

2110.Cache_inv_bench.c

1348.Cache_bench.cfg

Best regards,

Janet

Processors

Processors forum

Syslink Notify latency in Linux