public inbox for ecos-discuss@sourceware.org
 help / color / mirror / Atom feed
* [ECOS] Problem with CPU Load Measurements and gcc-arm-eabi optimization.
@ 2014-11-17 13:06 lesc
  2014-11-17 17:47 ` AW: " Richard Rauch
  0 siblings, 1 reply; 4+ messages in thread
From: lesc @ 2014-11-17 13:06 UTC (permalink / raw)
  To: eCos Discussion

Hello Everyone

I just encountered the Problem that the cyg_cpuload_create always 
delivers 100% on my System. After a bit of debugging I figured out, that 
the whole for-loop in idle_thread_main seems to be omitted.

I could fix this Problem with declaring 
idle_thread_loops[CYGNUM_KERNEL_CPU_MAX] as volatile (patch below). But 
this has maybe some consequences I am not thinking of, as the variables 
are now always synced to the ram and no kept in a CPU register.

Do you see any Problem with my approach?

Regards Serafin

Patch:

 From 2799f68a5e508c6bece6ec85b1e201282983b98d Mon Sep 17 00:00:00 2001
From: Serafin Leschke <lesc@zhaw.ch>
Date: Mon, 17 Nov 2014 13:51:23 +0100
Subject: [PATCH] declare idle_thread_loops as volatile

---
  packages/kernel/current/src/common/thread.cxx | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/packages/kernel/current/src/common/thread.cxx 
b/packages/kernel/current/src/common/thread.cxx
index 86a3dc4..bd1aa99 100644
--- a/packages/kernel/current/src/common/thread.cxx
+++ b/packages/kernel/current/src/common/thread.cxx
@@ -1211,7 +1211,7 @@ Cyg_ThreadTimer::alarm(
  #endif // CYGNUM_HAL_STACK_SIZE_MINIMUM

  // Loop counter for debugging/housekeeping
-cyg_uint32 idle_thread_loops[CYGNUM_KERNEL_CPU_MAX];
+volatile cyg_uint32 idle_thread_loops[CYGNUM_KERNEL_CPU_MAX];

  static char 
idle_thread_stack[CYGNUM_KERNEL_CPU_MAX][CYGNUM_KERNEL_THREADS_IDLE_STACK_SIZE];

-- 
1.9.1


-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

^ permalink raw reply	[flat|nested] 4+ messages in thread

* AW: [ECOS] Problem with CPU Load Measurements and gcc-arm-eabi optimization.
  2014-11-17 13:06 [ECOS] Problem with CPU Load Measurements and gcc-arm-eabi optimization lesc
@ 2014-11-17 17:47 ` Richard Rauch
  2014-11-18  9:26   ` lesc
  0 siblings, 1 reply; 4+ messages in thread
From: Richard Rauch @ 2014-11-17 17:47 UTC (permalink / raw)
  To: 'lesc', 'eCos Discussion'

Hello,

are you sure, that you are using current version of eCos?
This issue should be already solved. Current version has "volatile" keyword as you proposed!

Richard Rauch
www.itrgmbh.com


> -----Ursprüngliche Nachricht-----
> Von: ecos-discuss-owner@ecos.sourceware.org [mailto:ecos-discuss-
> owner@ecos.sourceware.org] Im Auftrag von lesc
> Gesendet: Montag, 17. November 2014 14:07
> An: eCos Discussion
> Betreff: [ECOS] Problem with CPU Load Measurements and gcc-arm-eabi
> optimization.
> 
> Hello Everyone
> 
> I just encountered the Problem that the cyg_cpuload_create always delivers
> 100% on my System. After a bit of debugging I figured out, that the whole
> for-loop in idle_thread_main seems to be omitted.
> 
> I could fix this Problem with declaring
> idle_thread_loops[CYGNUM_KERNEL_CPU_MAX] as volatile (patch below).
> But this has maybe some consequences I am not thinking of, as the variables
> are now always synced to the ram and no kept in a CPU register.
> 
> Do you see any Problem with my approach?
> 
> Regards Serafin
> 
> Patch:
> 
>  From 2799f68a5e508c6bece6ec85b1e201282983b98d Mon Sep 17 00:00:00
> 2001
> From: Serafin Leschke <lesc@zhaw.ch>
> Date: Mon, 17 Nov 2014 13:51:23 +0100
> Subject: [PATCH] declare idle_thread_loops as volatile
> 
> ---
>   packages/kernel/current/src/common/thread.cxx | 2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/packages/kernel/current/src/common/thread.cxx
> b/packages/kernel/current/src/common/thread.cxx
> index 86a3dc4..bd1aa99 100644
> --- a/packages/kernel/current/src/common/thread.cxx
> +++ b/packages/kernel/current/src/common/thread.cxx
> @@ -1211,7 +1211,7 @@ Cyg_ThreadTimer::alarm(
>   #endif // CYGNUM_HAL_STACK_SIZE_MINIMUM
> 
>   // Loop counter for debugging/housekeeping
> -cyg_uint32 idle_thread_loops[CYGNUM_KERNEL_CPU_MAX];
> +volatile cyg_uint32 idle_thread_loops[CYGNUM_KERNEL_CPU_MAX];
> 
>   static char
> idle_thread_stack[CYGNUM_KERNEL_CPU_MAX][CYGNUM_KERNEL_THREA
> DS_IDLE_STACK_SIZE];
> 
> --
> 1.9.1
> 
> 
> --
> Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
> and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss



--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: AW: [ECOS] Problem with CPU Load Measurements and gcc-arm-eabi optimization.
  2014-11-17 17:47 ` AW: " Richard Rauch
@ 2014-11-18  9:26   ` lesc
  0 siblings, 0 replies; 4+ messages in thread
From: lesc @ 2014-11-18  9:26 UTC (permalink / raw)
  To: Richard Rauch, eCos Discussion

Hi Richard

Thanks for the fast answer. This is a little embarrassing, I managed to 
find the commit you are referring to:

http://hg-pub.ecoscentric.com/ecos/rev/041821fb5427

The Version of Ecos I (have to) use is a port for the Xilinx Zynq Platform:
  https://github.com/antmicro/ecos-mars-zx3
Why they not just make a ecos package for the hal - instead of forking - 
I don't know (I'm quite new to the industry). Their version seems to be 
built on the ecos-v3 branch in which the above mentioned commit does not 
seem to me merged:
http://hg-pub.ecoscentric.com/ecos-v3_0-branch/file/7d8c61e6225c/packages/kernel/current/src/common/thread.cxx

So maybe I should read a bit more about the ecos release model to find 
out which version I should use in future.

Serafin



On 17.11.2014 18:47, Richard Rauch wrote:
> Hello,
>
> are you sure, that you are using current version of eCos?
> This issue should be already solved. Current version has "volatile" keyword as you proposed!
>
> Richard Rauch
> www.itrgmbh.com
>
>
>> -----Ursprüngliche Nachricht-----
>> Von: ecos-discuss-owner@ecos.sourceware.org [mailto:ecos-discuss-
>> owner@ecos.sourceware.org] Im Auftrag von lesc
>> Gesendet: Montag, 17. November 2014 14:07
>> An: eCos Discussion
>> Betreff: [ECOS] Problem with CPU Load Measurements and gcc-arm-eabi
>> optimization.
>>
>> Hello Everyone
>>
>> I just encountered the Problem that the cyg_cpuload_create always delivers
>> 100% on my System. After a bit of debugging I figured out, that the whole
>> for-loop in idle_thread_main seems to be omitted.
>>
>> I could fix this Problem with declaring
>> idle_thread_loops[CYGNUM_KERNEL_CPU_MAX] as volatile (patch below).
>> But this has maybe some consequences I am not thinking of, as the variables
>> are now always synced to the ram and no kept in a CPU register.
>>
>> Do you see any Problem with my approach?
>>
>> Regards Serafin
>>
>> Patch:
>>
>>   From 2799f68a5e508c6bece6ec85b1e201282983b98d Mon Sep 17 00:00:00
>> 2001
>> From: Serafin Leschke <lesc@zhaw.ch>
>> Date: Mon, 17 Nov 2014 13:51:23 +0100
>> Subject: [PATCH] declare idle_thread_loops as volatile
>>
>> ---
>>    packages/kernel/current/src/common/thread.cxx | 2 +-
>>    1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/packages/kernel/current/src/common/thread.cxx
>> b/packages/kernel/current/src/common/thread.cxx
>> index 86a3dc4..bd1aa99 100644
>> --- a/packages/kernel/current/src/common/thread.cxx
>> +++ b/packages/kernel/current/src/common/thread.cxx
>> @@ -1211,7 +1211,7 @@ Cyg_ThreadTimer::alarm(
>>    #endif // CYGNUM_HAL_STACK_SIZE_MINIMUM
>>
>>    // Loop counter for debugging/housekeeping
>> -cyg_uint32 idle_thread_loops[CYGNUM_KERNEL_CPU_MAX];
>> +volatile cyg_uint32 idle_thread_loops[CYGNUM_KERNEL_CPU_MAX];
>>
>>    static char
>> idle_thread_stack[CYGNUM_KERNEL_CPU_MAX][CYGNUM_KERNEL_THREA
>> DS_IDLE_STACK_SIZE];
>>
>> --
>> 1.9.1
>>
>>
>> --
>> Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
>> and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
>

-- 
Serafin Leschke, BSc in Computer Sience UAS Zurich
Research Assistant

ZHAW, Zurich University of Applied Sciences
InES, Institute of Embedded Systems
Postfach
Technikumstr. 22
CH-8401 Winterthur
--
Tel: +41 58 934 69 79
Fax: +41 58 935 76 87
E-Mail: serafin.lescke@zhaw.ch
Web: http://ines.zhaw.ch
--


-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: AW: [ECOS] Problem with CPU Load Measurements and gcc-arm-eabi optimization.
@ 2014-11-20 18:34 Tomasz Gorochowik
  0 siblings, 0 replies; 4+ messages in thread
From: Tomasz Gorochowik @ 2014-11-20 18:34 UTC (permalink / raw)
  To: lesc, rrauch, ecos-discuss

Hello,

as an Antmicro employee I would like to add a few words.

First of all, we're really glad you're using our eCos port, and we're
thankful for your report.

Nevertheless in the future I would suggest to create an issue on our
github page if you have any problems with our port. We'd be very happy
to help, and this way we can do this much faster.

This fix has already been merged into our repo, but not into the
master branch, it was on a branch called master-next. Right now
however we have merged it into master, and the newest eCos version
(checked out from eCos CVS today) is present on the master-next
branch.

Tomasz Gorochowik
Antmicro Ltd.
www.antmicro.com


> Hi Richard
>
> Thanks for the fast answer. This is a little embarrassing, I managed to find the commit you are referring to:
>
> http://hg-pub.ecoscentric.com/ecos/rev/041821fb5427
>
> The Version of Ecos I (have to) use is a port for the Xilinx Zynq Platform:
>  https://github.com/antmicro/ecos-mars-zx3
> Why they not just make a ecos package for the hal - instead of forking - I don't know (I'm quite new to the industry). Their version seems to be built on the ecos-v3 branch in which the above mentioned commit does not seem to me merged:
> http://hg-pub.ecoscentric.com/ecos-v3_0-branch/file/7d8c61e6225c/packages/kernel/current/src/common/thread.cxx
>
> So maybe I should read a bit more about the ecos release model to find out which version I should use in future.
>
> Serafin
>
>
>
> On 17.11.2014 18:47, Richard Rauch wrote:
>>
>> Hello,
>>
>> are you sure, that you are using current version of eCos?
>> This issue should be already solved. Current version has "volatile" keyword as you proposed!
>>
>> Richard Rauch
>> www.itrgmbh.com
>>
>>
>>> -----Ursprüngliche Nachricht-----
>>> Von: ecos-discuss-owner@ecos.sourceware.org [mailto:ecos-discuss-
>>> owner@ecos.sourceware.org] Im Auftrag von lesc
>>> Gesendet: Montag, 17. November 2014 14:07
>>> An: eCos Discussion
>>> Betreff: [ECOS] Problem with CPU Load Measurements and gcc-arm-eabi
>>> optimization.
>>>
>>> Hello Everyone
>>>
>>> I just encountered the Problem that the cyg_cpuload_create always delivers
>>> 100% on my System. After a bit of debugging I figured out, that the whole
>>> for-loop in idle_thread_main seems to be omitted.
>>>
>>> I could fix this Problem with declaring
>>> idle_thread_loops[CYGNUM_KERNEL_CPU_MAX] as volatile (patch below).
>>> But this has maybe some consequences I am not thinking of, as the variables
>>> are now always synced to the ram and no kept in a CPU register.
>>>
>>> Do you see any Problem with my approach?
>>>
>>> Regards Serafin
>>>
>>> Patch:
>>>
>>>   From 2799f68a5e508c6bece6ec85b1e201282983b98d Mon Sep 17 00:00:00
>>> 2001
>>> From: Serafin Leschke <lesc@zhaw.ch>
>>> Date: Mon, 17 Nov 2014 13:51:23 +0100
>>> Subject: [PATCH] declare idle_thread_loops as volatile
>>>
>>> ---
>>>    packages/kernel/current/src/common/thread.cxx | 2 +-
>>>    1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/packages/kernel/current/src/common/thread.cxx
>>> b/packages/kernel/current/src/common/thread.cxx
>>> index 86a3dc4..bd1aa99 100644
>>> --- a/packages/kernel/current/src/common/thread.cxx
>>> +++ b/packages/kernel/current/src/common/thread.cxx
>>> @@ -1211,7 +1211,7 @@ Cyg_ThreadTimer::alarm(
>>>    #endif // CYGNUM_HAL_STACK_SIZE_MINIMUM
>>>
>>>    // Loop counter for debugging/housekeeping
>>> -cyg_uint32 idle_thread_loops[CYGNUM_KERNEL_CPU_MAX];
>>> +volatile cyg_uint32 idle_thread_loops[CYGNUM_KERNEL_CPU_MAX];
>>>
>>>    static char
>>> idle_thread_stack[CYGNUM_KERNEL_CPU_MAX][CYGNUM_KERNEL_THREA
>>> DS_IDLE_STACK_SIZE];
>>>
>>> --
>>> 1.9.1
>>>
>>>
>>> --
>>> Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
>>> and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2014-11-20 18:34 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-11-17 13:06 [ECOS] Problem with CPU Load Measurements and gcc-arm-eabi optimization lesc
2014-11-17 17:47 ` AW: " Richard Rauch
2014-11-18  9:26   ` lesc
2014-11-20 18:34 Tomasz Gorochowik

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).