* [Xenomai] Disable L2 write allocate on iMX6q @ 2014-04-18 10:00 Mauro Salvini 2014-04-18 11:29 ` Gilles Chanteperdrix 0 siblings, 1 reply; 5+ messages in thread From: Mauro Salvini @ 2014-04-18 10:00 UTC (permalink / raw) To: xenomai Hello, I'm testing an iMX6q Sabrelite board from Element14 with Xenomai 2.6.3. First of all I tried kernel 3.0.43 from Xenomai git branch ipipe-3.0-imx6q. This kernel works well, a 15 hours running latency test (with manually generated system load like dd, netcat, ssh) shows an average latency of 5.690us and a worst case latency of 42.186us. Then I tried 3.4.6 vanilla kernel, but in this case latency test average result for is a bit worse, with a value around 18us. Worst case is about the same (<50us). I read in mailing list that L2 write allocate is disabled in 3.0.43 kernel (in facts log says: l2x0: 16 ways, CACHE_ID 0x410000c7, AUX_CTRL 0x02870000, Cache size: 1048576 B). This feature is enabled in 3.4.6 kernel ( log says: l2x0: 16 ways, CACHE_ID 0x410000c7, AUX_CTRL 0x02070000, Cache size: 1048576 B). Could this be the cause of latency degradation observed in 3.4.6 kernel? I also tried 3.8.13 with same results. Kernel configurations are the default ones for each kernel, with hw_perf disabled. Thanks in advance Mauro ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [Xenomai] Disable L2 write allocate on iMX6q 2014-04-18 10:00 [Xenomai] Disable L2 write allocate on iMX6q Mauro Salvini @ 2014-04-18 11:29 ` Gilles Chanteperdrix 2014-04-18 12:08 ` Mauro Salvini 0 siblings, 1 reply; 5+ messages in thread From: Gilles Chanteperdrix @ 2014-04-18 11:29 UTC (permalink / raw) To: Mauro Salvini; +Cc: xenomai On 04/18/2014 12:00 PM, Mauro Salvini wrote: > Hello, > I'm testing an iMX6q Sabrelite board from Element14 with Xenomai 2.6.3. > > First of all I tried kernel 3.0.43 from Xenomai git branch > ipipe-3.0-imx6q. This kernel works well, a 15 hours running latency test > (with manually generated system load like dd, netcat, ssh) shows an > average latency of 5.690us and a worst case latency of 42.186us. > Then I tried 3.4.6 vanilla kernel, but in this case latency test average > result for is a bit worse, with a value around 18us. Worst case is about > the same (<50us). > I read in mailing list that L2 write allocate is disabled in 3.0.43 > kernel (in facts log says: l2x0: 16 ways, CACHE_ID 0x410000c7, AUX_CTRL > 0x02870000, Cache size: 1048576 B). > This feature is enabled in 3.4.6 kernel ( log says: l2x0: 16 ways, > CACHE_ID 0x410000c7, AUX_CTRL 0x02070000, Cache size: 1048576 B). Could > this be the cause of latency degradation observed in 3.4.6 kernel? I > also tried 3.8.13 with same results. > Kernel configurations are the default ones for each kernel, with hw_perf > disabled. Yes, L2 write allocate on imx6 has disastrous effects on latency. L2 write allocate is disabled starting from the 3.10 kernel for the mainline I-pipe patches. See branch ipipe-3.10 in ipipe.git. The patch which disables L2 write allocate is: http://git.xenomai.org/ipipe.git/commit/?h=ipipe-3.10&id=05d6bcc014821c286248f6f4c1c953fcbde67f27 and is probably easy to backport to earlier branches (but why would you want to use a 3.4 kernel anyway?). -- Gilles. ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [Xenomai] Disable L2 write allocate on iMX6q 2014-04-18 11:29 ` Gilles Chanteperdrix @ 2014-04-18 12:08 ` Mauro Salvini 2014-04-18 12:11 ` Gilles Chanteperdrix 0 siblings, 1 reply; 5+ messages in thread From: Mauro Salvini @ 2014-04-18 12:08 UTC (permalink / raw) To: Gilles Chanteperdrix; +Cc: xenomai On Fri, 2014-04-18 at 13:29 +0200, Gilles Chanteperdrix wrote: > On 04/18/2014 12:00 PM, Mauro Salvini wrote: > > Hello, > > I'm testing an iMX6q Sabrelite board from Element14 with Xenomai 2.6.3. > > > > First of all I tried kernel 3.0.43 from Xenomai git branch > > ipipe-3.0-imx6q. This kernel works well, a 15 hours running latency test > > (with manually generated system load like dd, netcat, ssh) shows an > > average latency of 5.690us and a worst case latency of 42.186us. > > Then I tried 3.4.6 vanilla kernel, but in this case latency test average > > result for is a bit worse, with a value around 18us. Worst case is about > > the same (<50us). > > I read in mailing list that L2 write allocate is disabled in 3.0.43 > > kernel (in facts log says: l2x0: 16 ways, CACHE_ID 0x410000c7, AUX_CTRL > > 0x02870000, Cache size: 1048576 B). > > This feature is enabled in 3.4.6 kernel ( log says: l2x0: 16 ways, > > CACHE_ID 0x410000c7, AUX_CTRL 0x02070000, Cache size: 1048576 B). Could > > this be the cause of latency degradation observed in 3.4.6 kernel? I > > also tried 3.8.13 with same results. > > Kernel configurations are the default ones for each kernel, with hw_perf > > disabled. > > Yes, L2 write allocate on imx6 has disastrous effects on latency. > L2 write allocate is disabled starting from the 3.10 kernel for the > mainline I-pipe patches. See branch ipipe-3.10 in ipipe.git. > > The patch which disables L2 write allocate is: > http://git.xenomai.org/ipipe.git/commit/?h=ipipe-3.10&id=05d6bcc014821c286248f6f4c1c953fcbde67f27 > > and is probably easy to backport to earlier branches (but why would you > want to use a 3.4 kernel anyway?). > Thank you very much, I will try the patch. I haven't a strict need to use 3.4 kernel, it was only a test. By the way, is there a general rule to follow to choose a kernel version for an ARM architecture (e.g. latest kernel release against older but most-SOC-optimized release)? For example, for Xenomai 2.6.3 there are three ipipe patches (for 3.4.6, 3.5.7 and 3.8.13 kernels), but as stated into README file iMXQ6 should use ipipe patch contained into mcx dir, that is for 3.0.43 kernel . Thank you in advance Mauro ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [Xenomai] Disable L2 write allocate on iMX6q 2014-04-18 12:08 ` Mauro Salvini @ 2014-04-18 12:11 ` Gilles Chanteperdrix 2014-04-18 12:14 ` Mauro Salvini 0 siblings, 1 reply; 5+ messages in thread From: Gilles Chanteperdrix @ 2014-04-18 12:11 UTC (permalink / raw) To: Mauro Salvini; +Cc: xenomai On 04/18/2014 02:08 PM, Mauro Salvini wrote: > On Fri, 2014-04-18 at 13:29 +0200, Gilles Chanteperdrix wrote: > >> On 04/18/2014 12:00 PM, Mauro Salvini wrote: >>> Hello, >>> I'm testing an iMX6q Sabrelite board from Element14 with Xenomai 2.6.3. >>> >>> First of all I tried kernel 3.0.43 from Xenomai git branch >>> ipipe-3.0-imx6q. This kernel works well, a 15 hours running latency test >>> (with manually generated system load like dd, netcat, ssh) shows an >>> average latency of 5.690us and a worst case latency of 42.186us. >>> Then I tried 3.4.6 vanilla kernel, but in this case latency test average >>> result for is a bit worse, with a value around 18us. Worst case is about >>> the same (<50us). >>> I read in mailing list that L2 write allocate is disabled in 3.0.43 >>> kernel (in facts log says: l2x0: 16 ways, CACHE_ID 0x410000c7, AUX_CTRL >>> 0x02870000, Cache size: 1048576 B). >>> This feature is enabled in 3.4.6 kernel ( log says: l2x0: 16 ways, >>> CACHE_ID 0x410000c7, AUX_CTRL 0x02070000, Cache size: 1048576 B). Could >>> this be the cause of latency degradation observed in 3.4.6 kernel? I >>> also tried 3.8.13 with same results. >>> Kernel configurations are the default ones for each kernel, with hw_perf >>> disabled. >> >> Yes, L2 write allocate on imx6 has disastrous effects on latency. >> L2 write allocate is disabled starting from the 3.10 kernel for the >> mainline I-pipe patches. See branch ipipe-3.10 in ipipe.git. >> >> The patch which disables L2 write allocate is: >> http://git.xenomai.org/ipipe.git/commit/?h=ipipe-3.10&id=05d6bcc014821c286248f6f4c1c953fcbde67f27 >> >> and is probably easy to backport to earlier branches (but why would you >> want to use a 3.4 kernel anyway?). >> > > Thank you very much, I will try the patch. > > I haven't a strict need to use 3.4 kernel, it was only a test. By the > way, is there a general rule to follow to choose a kernel version for an > ARM architecture (e.g. latest kernel release against older but > most-SOC-optimized release)? For example, for Xenomai 2.6.3 there are > three ipipe patches (for 3.4.6, 3.5.7 and 3.8.13 kernels), but as stated > into README file iMXQ6 should use ipipe patch contained into mcx dir, > that is for 3.0.43 kernel . No, the README does not say that you should use the patch for the 3.0.43 kernel. The patch is there IN CASE you want to use that kernel, because that kernel is based on the one provided by Freescale. But you are very much encouraged to use more recent mainline releases. -- Gilles. ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [Xenomai] Disable L2 write allocate on iMX6q 2014-04-18 12:11 ` Gilles Chanteperdrix @ 2014-04-18 12:14 ` Mauro Salvini 0 siblings, 0 replies; 5+ messages in thread From: Mauro Salvini @ 2014-04-18 12:14 UTC (permalink / raw) To: Gilles Chanteperdrix; +Cc: xenomai On Fri, 2014-04-18 at 14:11 +0200, Gilles Chanteperdrix wrote: > On 04/18/2014 02:08 PM, Mauro Salvini wrote: > > On Fri, 2014-04-18 at 13:29 +0200, Gilles Chanteperdrix wrote: > > > >> On 04/18/2014 12:00 PM, Mauro Salvini wrote: > >>> Hello, > >>> I'm testing an iMX6q Sabrelite board from Element14 with Xenomai 2.6.3. > >>> > >>> First of all I tried kernel 3.0.43 from Xenomai git branch > >>> ipipe-3.0-imx6q. This kernel works well, a 15 hours running latency test > >>> (with manually generated system load like dd, netcat, ssh) shows an > >>> average latency of 5.690us and a worst case latency of 42.186us. > >>> Then I tried 3.4.6 vanilla kernel, but in this case latency test average > >>> result for is a bit worse, with a value around 18us. Worst case is about > >>> the same (<50us). > >>> I read in mailing list that L2 write allocate is disabled in 3.0.43 > >>> kernel (in facts log says: l2x0: 16 ways, CACHE_ID 0x410000c7, AUX_CTRL > >>> 0x02870000, Cache size: 1048576 B). > >>> This feature is enabled in 3.4.6 kernel ( log says: l2x0: 16 ways, > >>> CACHE_ID 0x410000c7, AUX_CTRL 0x02070000, Cache size: 1048576 B). Could > >>> this be the cause of latency degradation observed in 3.4.6 kernel? I > >>> also tried 3.8.13 with same results. > >>> Kernel configurations are the default ones for each kernel, with hw_perf > >>> disabled. > >> > >> Yes, L2 write allocate on imx6 has disastrous effects on latency. > >> L2 write allocate is disabled starting from the 3.10 kernel for the > >> mainline I-pipe patches. See branch ipipe-3.10 in ipipe.git. > >> > >> The patch which disables L2 write allocate is: > >> http://git.xenomai.org/ipipe.git/commit/?h=ipipe-3.10&id=05d6bcc014821c286248f6f4c1c953fcbde67f27 > >> > >> and is probably easy to backport to earlier branches (but why would you > >> want to use a 3.4 kernel anyway?). > >> > > > > Thank you very much, I will try the patch. > > > > I haven't a strict need to use 3.4 kernel, it was only a test. By the > > way, is there a general rule to follow to choose a kernel version for an > > ARM architecture (e.g. latest kernel release against older but > > most-SOC-optimized release)? For example, for Xenomai 2.6.3 there are > > three ipipe patches (for 3.4.6, 3.5.7 and 3.8.13 kernels), but as stated > > into README file iMXQ6 should use ipipe patch contained into mcx dir, > > that is for 3.0.43 kernel . > > No, the README does not say that you should use the patch for the 3.0.43 > kernel. The patch is there IN CASE you want to use that kernel, because > that kernel is based on the one provided by Freescale. But you are very > much encouraged to use more recent mainline releases. > Sorry, my misunderstanding. Thanks again. ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2014-04-18 12:14 UTC | newest] Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2014-04-18 10:00 [Xenomai] Disable L2 write allocate on iMX6q Mauro Salvini 2014-04-18 11:29 ` Gilles Chanteperdrix 2014-04-18 12:08 ` Mauro Salvini 2014-04-18 12:11 ` Gilles Chanteperdrix 2014-04-18 12:14 ` Mauro Salvini
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.