Hi,

Some interesting insights about my last tests.

1.) The culprit is mlockall(MCL_FUTURE|MCL_CURRENT);

As soon I leave this away, I get much better results:

Without mlockall():
Test (10) memcpy of sizes (10485760)
10 memcpy. Time per memcpy: 78147209 [nsec] (134 MB/sec)
 finished.

With mlockall():
Test (10) memcpy of sizes (10485760) ....
10 memcpy. Time per memcpy: 124194618 [nsec] (84 MB/sec)
 finished.

Then again I cannot use Xenomai without mlockall() 
:(

2.) rt_timer_tsc
If I use clock_gettime() this needs 3100 ns,
If I use rt_timer_tsc() this needs 74 (!) ns.


Oooh, we are using clock_gettime() a lot, so this makes a big difference for us.

Best regards,

-- 
Daniel Schnell                   | [EMAIL PROTECTED]
Hugbúnaðargerð                   | www.marel.com

-----Original Message-----
From: Gilles Chanteperdrix [mailto:[EMAIL PROTECTED] 
Sent: 15. maí 2007 14:51
To: Daniel Schnell
Cc: [email protected]
Subject: Re: [Xenomai-help] memcpy performance on Xenomai

Daniel Schnell wrote:
> > -----Original Message-----
> > From: Gilles Chanteperdrix [mailto:[EMAIL PROTECTED]
> > Sent: 15. maí 2007 12:16
> > To: Daniel Schnell
> > Cc: [email protected]
> > Subject: Re: [Xenomai-help] memcpy performance on Xenomai
> >
> >
> > Improving clock_gettime overhead by reading directly the tsc is my very 
> > next task. If you want to check if the effect you measure is the result of 
> > clock_gettime overhead, you can measure the duration of memcpy with the 
> > native api service rt_timer_tsc, and convert the tsc difference with 
> > rt_timer_tsc2ns.
> 
> This was not the culprit. Same results.

Does your processor have a tsc ? If yes, do you compile Xenomai with 
--enable-x86-tsc ? What happens if you disable the interruptions ?

> 
> Does Xenomai replace the memcpy() call with an own implementation ? (I 
> don't think so.)
> 
> What about trashing of cash lines through context switches ? But then if we 
> run it on Linux alone we should also have trashed cache lines. There should 
> not be any difference.
> Is maybe the presence of a Xenomai POSIX thread cause a lot of ctx switches, 
> even if only a memcpy is executed inside the thread ? Shouldn't Xenomai 
> threads run totally uninterrupted if they have the highest prio ?
> 
> Please could somebody actually run this test on his hardware and see if these 
> differences between Xenomai POSIX skin and Linux native are happening there 
> as well ?

If you want us to test the code, please send it, I mean the one adapted to the 
native skin.

-- 
                                                 Gilles Chanteperdrix

_______________________________________________
Xenomai-help mailing list
[email protected]
https://mail.gna.org/listinfo/xenomai-help

Reply via email to