RE: [PATCH 1/5] capture: Removal of capture task tracking.
I tried to limit how much functionality I removed from the capture engine with
this
set of patches and limit it to what had to be removed in order to support
removal of
capture tasks. I have no problem with it moving to cpuuse, but I think it
would need to
be modified to use a printk plugin and account for
__RTEMS_USE_TICKS_FOR_STATISTICS__ .
jennifer
> -Original Message-
> From: devel [mailto:devel-boun...@rtems.org] On Behalf Of Chris Johns
> Sent: Monday, September 22, 2014 4:57 PM
> To: devel@rtems.org
> Subject: Re: [PATCH 1/5] capture: Removal of capture task tracking.
>
> On 23/09/2014 12:00 am, Jennifer Averett wrote:
> > This patch removes functionality for stack checking from
> > the capture engine and requiresi the use of existing rtems
> > functions for this information. It modifies ctload to use
> > functionality similar to rtems cpuusage. It removes the
> > capture task and stores a new capture task record the first
> > time the task is seen. The per task data that was still
> > needed is scaled down and stored in the tcb.
>
> If the capture engine is not needed for ctload to work why not move that
> code out of here and into the cpuuse command ? It would appear more
> available to users.
>
> > ---
> > cpukit/libmisc/capture/capture-cli.c| 383
> > ++--
> > cpukit/libmisc/capture/capture.c| 367
> > ++-
> > cpukit/libmisc/capture/capture.h| 295 --
> > cpukit/libmisc/capture/capture_user_extension.c | 219 +++---
> > cpukit/libmisc/capture/captureimpl.h| 53 +---
> > 5 files changed, 420 insertions(+), 897 deletions(-)
> >
> > diff --git a/cpukit/libmisc/capture/capture-cli.c
> b/cpukit/libmisc/capture/capture-cli.c
> > index 2aa7c9c..6fe7e6c 100644
> > --- a/cpukit/libmisc/capture/capture-cli.c
> > +++ b/cpukit/libmisc/capture/capture-cli.c
> > @@ -35,12 +35,28 @@
> > #include
> > #include
> > #include
> > -
> > +#include
> > +#
> > #define RC_UNUSED __attribute__((unused))
> >
> > #define RTEMS_CAPTURE_CLI_MAX_LOAD_TASKS (20)
> >
> > /*
> > + * Counter used to count the number of active tasks.
> > + */
> > +static int rtems_capture_cli_task_count = 0;
> > +
> > +/*
> > + * Array of tasks sorted by load.
> > + */
> > +static rtems_tcb*
> rtems_capture_cli_load_tasks[RTEMS_CAPTURE_CLI_MAX_LOAD_TASKS +
> 1];
> > +
> > +/*
> > + * The load for each tcb at the moment rtems_capture_cli_load_tasks was
> generated.
> > + */
> > +static unsigned long long
> rtems_capture_cli_load[RTEMS_CAPTURE_CLI_MAX_LOAD_TASKS + 1];
> > +
> > +/*
> >* The user capture timestamper.
> >*/
> > static rtems_capture_timestamp capture_timestamp;
> > @@ -233,6 +249,104 @@ rtems_capture_cli_print_timestamp (uint64_t
> uptime)
> > fprintf (stdout, "%5lu:%02lu:%02lu.%09lu", hours, minutes, seconds,
> nanosecs);
> > }
> >
> > +static void
> > +rtems_capture_cli_print_task (rtems_tcb *tcb)
> > +{
> > + rtems_task_priority ceiling = rtems_capture_watch_get_ceiling ();
> > + rtems_task_priority floor = rtems_capture_watch_get_floor ();
> > + rtems_task_priority priority;
> > + int length;
> > +
> > + priority = rtems_capture_task_real_priority (tcb);
> > +
> > + fprintf (stdout, " ");
> > + rtems_monitor_dump_id (rtems_capture_task_id (tcb));
> > + fprintf (stdout, " ");
> > + rtems_monitor_dump_name (rtems_capture_task_id (tcb));
> > + fprintf (stdout, " ");
> > + rtems_monitor_dump_priority (rtems_capture_task_start_priority
> (tcb));
> > + fprintf (stdout, " ");
> > + rtems_monitor_dump_priority (rtems_capture_task_real_priority (tcb));
> > + fprintf (stdout, " ");
> > + rtems_monitor_dump_priority (rtems_capture_task_curr_priority
> (tcb));
> > + fprintf (stdout, " ");
> > + length = rtems_monitor_dump_state (rtems_capture_task_state (tcb));
> > + fprintf (stdout, "%*c", 14 - length, ' ');
> > + fprintf (stdout, " %c%c",
> > + 'a',
> > + rtems_capture_task_flags (tcb) & RTEMS_CAPTURE_TRACED ? 't' : '-
> ');
> > +
> > + if ((floor > ceiling) && (ceiling > priority))
> > +fprintf (stdout, "--");
> > + else
> > + {
> > +uint32_t flags = rtems_capture_task_control_flags (tcb);
> > +fprintf (stdout, "%c%c",
> > + rtems_capture_task_control (tcb) ?
> > + (flags & RTEMS_CAPTURE_WATCH ? 'w' : '+') : '-',
> > + rtems_capture_watch_global_on () ? 'g' : '-');
> > + }
> > + fprintf (stdout, "\n");
> > +}
> > +static void
> > +rtems_caputure_cli_print_record_std(rtems_capture_record_t* rec,
> uint64_t diff)
> > +{
> > + uint32_t event;
> > + int e;
> > +
> > + event = rec->events >> RTEMS_CAPTURE_EVENT_START;
> > +
> > + for (e = RTEMS_CAPTURE_EVENT_START; e <
> RTEMS_CAPTURE_EVENT_END; e++)
> > + {
> > +if (event & 1)
> > +{
> > + rtems_capture_cli_print_timestamp
Re: [rtems commit] m68k: Use CPU_TIMESTAMP_USE_STRUCT_TIMESPEC
The code is m68k and the comment is PowerPC.
Any guidance for the porting guide on what constitutes too expensive? There
should be some general guidelines regarding when to pick a format bases on that.
Also.. This means that some ports will have 2038 issues at the score level. We
have to address 64 bit time_t at some point.
On September 23, 2014 3:42:48 AM CDT, Sebastian Huber wrote:
>Module:rtems
>Branch:master
>Commit:5323247c3148a22baefb1590533972c401f7d745
>Changeset:
>http://git.rtems.org/rtems/commit/?id=5323247c3148a22baefb1590533972c401f7d745
>
>Author:Sebastian Huber
>Date: Tue Sep 23 08:01:56 2014 +0200
>
>m68k: Use CPU_TIMESTAMP_USE_STRUCT_TIMESPEC
>
>Converting 64-bit nanoseconds values into the common struct timeval or
>struct timespec formats requires a 64-bit division to get the seconds
>value. Performance analysis of high network loads revealed that this
>is
>too costly on PowerPC.
>
>---
>
> cpukit/score/cpu/m68k/rtems/score/cpu.h |2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
>diff --git a/cpukit/score/cpu/m68k/rtems/score/cpu.h
>b/cpukit/score/cpu/m68k/rtems/score/cpu.h
>index d222465..7d164f3 100644
>--- a/cpukit/score/cpu/m68k/rtems/score/cpu.h
>+++ b/cpukit/score/cpu/m68k/rtems/score/cpu.h
>@@ -102,7 +102,7 @@ extern "C" {
> #define CPU_STACK_GROWS_UP FALSE
> #define CPU_STRUCTURE_ALIGNMENT __attribute__ ((aligned (4)))
>
>-#define CPU_TIMESTAMP_USE_INT64_INLINE TRUE
>+#define CPU_TIMESTAMP_USE_STRUCT_TIMESPEC TRUE
>
> /*
>* Define what is required to specify how the network to host
>conversion
>
>___
>vc mailing list
>v...@rtems.org
>http://lists.rtems.org/mailman/listinfo/vc
--joel___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: [rtems commit] m68k: Use CPU_TIMESTAMP_USE_STRUCT_TIMESPEC
On Tue, Sep 23, 2014 at 11:38 AM, Joel Sherrill
wrote:
> The code is m68k and the comment is PowerPC.
>
> Any guidance for the porting guide on what constitutes too expensive? There
> should be some general guidelines regarding when to pick a format bases on
> that.
>
> Also.. This means that some ports will have 2038 issues at the score level.
> We have to address 64 bit time_t at some point.
>
It was proposed to use the bintime instead of 64-bit time_t (see [Bug
2180] New: _TOD_Get_with_nanoseconds() is broken on SMP)
-Gedare
>
> On September 23, 2014 3:42:48 AM CDT, Sebastian Huber
> wrote:
>>
>> Module:rtems
>> Branch:master
>> Commit:5323247c3148a22baefb1590533972c401f7d745
>> Changeset:
>> http://git.rtems.org/rtems/commit/?id=5323247c3148a22baefb1590533972c401f7d745
>>
>> Author:Sebastian Huber
>> Date: Tue Sep 23 08:01:56 2014 +0200
>>
>> m68k: Use CPU_TIMESTAMP_USE_STRUCT_TIMESPEC
>>
>> Converting 64-bit nanoseconds values into the common struct timeval or
>> struct timespec formats requires a 64-bit division to get the seconds
>> value. Performance analysis of high network loads revealed that this is
>> too costly on PowerPC.
>>
>> ---
>>
>> cpukit/score/cpu/m68k/rtems/score/cpu.h |2 +-
>> 1 files changed, 1 insertions(+), 1 deletions(-)
>>
>> diff --git a/cpukit/score/cpu/m68k/rtems/score/cpu.h
>> b/cpukit/score/cpu/m68k/rtems/score/cpu.hindex d222465..7d164f3 100644
>> --- a/cpukit/score/cpu/m68k/rtems/score/cpu.h
>> +++ b/cpukit/score/cpu/m68k/rtems/score/cpu.h
>> @@ -102,7 +102,7 @@ extern "C" {
>> #define CPU_STACK_GROWS_UP FALSE
>> #define CPU_STRUCTURE_ALIGNMENT __attribute__ ((aligned (4)))
>>
>> -#define CPU_TIMESTAMP_USE_INT64_INLINE TRUE
>> +#define CPU_TIMESTAMP_USE_STRUCT_TIMESPEC TRUE
>>
>> /*
>> * Define what is required to specify how the network to host conversion
>>
>>
>>
>> vc mailing list
>> v...@rtems.org
>> http://lists.rtems.org/mailman/listinfo/vc
>
>
> --joel
>
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH 1/5] capture: Removal of capture task tracking.
On 23/09/2014 10:29 pm, Jennifer Averett wrote: I tried to limit how much functionality I removed from the capture engine with this set of patches and limit it to what had to be removed in order to support removal of capture tasks. I have no problem with it moving to cpuuse, but I think it would need to be modified to use a printk plugin and account for __RTEMS_USE_TICKS_FOR_STATISTICS__ . This makes sense. Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [rtems commit] m68k: Use CPU_TIMESTAMP_USE_STRUCT_TIMESPEC
On 23/09/14 18:27, Gedare Bloom wrote:
On Tue, Sep 23, 2014 at 11:38 AM, Joel Sherrill
wrote:
The code is m68k and the comment is PowerPC.
Sorry, a copy and paste error.
I did performance tests on both platforms with FTP transfers to/from
"/dev/zero". I observed roughly 3% processor load in __divdi3() and __moddi3()
used by rtems_clock_get_uptime_timeval() and rtems_clock_get_uptime_seconds().
Any guidance for the porting guide on what constitutes too expensive? There
should be some general guidelines regarding when to pick a format bases on
that.
I think if a target uses __divdi3(), then it is too costly. The focus on
64-bit nanoseconds neglected that nearly all user API functions use seconds.
Also.. This means that some ports will have 2038 issues at the score level.
We have to address 64 bit time_t at some point.
Yes, we should move to 64-bit time_t after the next release or even now.
It was proposed to use the bintime instead of 64-bit time_t (see [Bug
2180] New: _TOD_Get_with_nanoseconds() is broken on SMP)
The bintime is
struct bintime {
time_t sec;
uint64_t frac;
};
Most operations with timestamps use subtraction and comparison. On most 32-bit
architectures this is efficient even for 64-bit values. The problem is the
division operation.
--
Sebastian Huber, embedded brains GmbH
Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone : +49 89 189 47 41-16
Fax : +49 89 189 47 41-09
E-Mail : sebastian.hu...@embedded-brains.de
PGP : Public key available on request.
Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: [rtems commit] m68k: Use CPU_TIMESTAMP_USE_STRUCT_TIMESPEC
On 24/09/2014 3:27 pm, Sebastian Huber wrote:
On 23/09/14 18:27, Gedare Bloom wrote:
On Tue, Sep 23, 2014 at 11:38 AM, Joel Sherrill
wrote:
The code is m68k and the comment is PowerPC.
Sorry, a copy and paste error.
I did performance tests on both platforms with FTP transfers to/from
"/dev/zero". I observed roughly 3% processor load in __divdi3() and
__moddi3() used by rtems_clock_get_uptime_timeval() and
rtems_clock_get_uptime_seconds().
Thanks.
Any guidance for the porting guide on what constitutes too expensive?
There
should be some general guidelines regarding when to pick a format
bases on
that.
I think if a target uses __divdi3(), then it is too costly. The focus
on 64-bit nanoseconds neglected that nearly all user API functions use
seconds.
Also.. This means that some ports will have 2038 issues at the score
level.
We have to address 64 bit time_t at some point.
Yes, we should move to 64-bit time_t after the next release or even now.
What is involved ?
It was proposed to use the bintime instead of 64-bit time_t (see [Bug
2180] New: _TOD_Get_with_nanoseconds() is broken on SMP)
The bintime is
struct bintime {
time_tsec;
uint64_t frac;
};
Most operations with timestamps use subtraction and comparison. On most
32-bit architectures this is efficient even for 64-bit values. The
problem is the division operation.
I am not sure understand what you are saying. Are you implying a
performance issue with bintime because it has a multiple to convert or
are you saying bintime ok to use ?
Chris
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: [rtems commit] m68k: Use CPU_TIMESTAMP_USE_STRUCT_TIMESPEC
On 24/09/14 07:34, Chris Johns wrote:
On 24/09/2014 3:27 pm, Sebastian Huber wrote:
On 23/09/14 18:27, Gedare Bloom wrote:
On Tue, Sep 23, 2014 at 11:38 AM, Joel Sherrill
wrote:
The code is m68k and the comment is PowerPC.
Sorry, a copy and paste error.
I did performance tests on both platforms with FTP transfers to/from
"/dev/zero". I observed roughly 3% processor load in __divdi3() and
__moddi3() used by rtems_clock_get_uptime_timeval() and
rtems_clock_get_uptime_seconds().
Thanks.
Any guidance for the porting guide on what constitutes too expensive?
There
should be some general guidelines regarding when to pick a format
bases on
that.
I think if a target uses __divdi3(), then it is too costly. The focus
on 64-bit nanoseconds neglected that nearly all user API functions use
seconds.
Also.. This means that some ports will have 2038 issues at the score
level.
We have to address 64 bit time_t at some point.
Yes, we should move to 64-bit time_t after the next release or even now.
What is involved ?
Something like this:
diff --git a/newlib/libc/include/machine/types.h
b/newlib/libc/include/machine/types.h
index 40a75fa..b7265b9 100644
--- a/newlib/libc/include/machine/types.h
+++ b/newlib/libc/include/machine/types.h
@@ -11,7 +11,7 @@
#endif
#define_CLOCK_T_ unsigned long /* clock() */
-#define_TIME_T_long/* time() */
+#define_TIME_T_long long /* time() */
#define _CLOCKID_T_unsigned long
#define _TIMER_T_ unsigned long
The problem is that, everyone using custom integer types and not time_t will
then probably have a problem. We have to figure out if there are spots in
RTEMS itself. It may help to enable the -Wconversion warnings for this, but I
guess this will trigger hundreds of warnings.
It was proposed to use the bintime instead of 64-bit time_t (see [Bug
2180] New: _TOD_Get_with_nanoseconds() is broken on SMP)
The bintime is
struct bintime {
time_tsec;
uint64_t frac;
};
Most operations with timestamps use subtraction and comparison. On most
32-bit architectures this is efficient even for 64-bit values. The
problem is the division operation.
I am not sure understand what you are saying. Are you implying a performance
issue with bintime because it has a multiple to convert or are you saying
bintime ok to use ?
Chris
The struct bintime is perfectly fine to use.
--
Sebastian Huber, embedded brains GmbH
Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone : +49 89 189 47 41-16
Fax : +49 89 189 47 41-09
E-Mail : sebastian.hu...@embedded-brains.de
PGP : Public key available on request.
Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: [rtems commit] m68k: Use CPU_TIMESTAMP_USE_STRUCT_TIMESPEC
On 24/09/2014 3:42 pm, Sebastian Huber wrote: On 24/09/14 07:34, Chris Johns wrote: On 24/09/2014 3:27 pm, Sebastian Huber wrote: Yes, we should move to 64-bit time_t after the next release or even now. What is involved ? Something like this: diff --git a/newlib/libc/include/machine/types.h b/newlib/libc/include/machine/types.h index 40a75fa..b7265b9 100644 --- a/newlib/libc/include/machine/types.h +++ b/newlib/libc/include/machine/types.h @@ -11,7 +11,7 @@ #endif #define_CLOCK_T_ unsigned long /* clock() */ -#define_TIME_T_long/* time() */ +#define_TIME_T_long long /* time() */ #define _CLOCKID_T_unsigned long #define _TIMER_T_ unsigned long This is common to all newlib users. Did you mean to do that ? Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [rtems commit] m68k: Use CPU_TIMESTAMP_USE_STRUCT_TIMESPEC
On 24/09/14 07:45, Chris Johns wrote: On 24/09/2014 3:42 pm, Sebastian Huber wrote: On 24/09/14 07:34, Chris Johns wrote: On 24/09/2014 3:27 pm, Sebastian Huber wrote: Yes, we should move to 64-bit time_t after the next release or even now. What is involved ? Something like this: diff --git a/newlib/libc/include/machine/types.h b/newlib/libc/include/machine/types.h index 40a75fa..b7265b9 100644 --- a/newlib/libc/include/machine/types.h +++ b/newlib/libc/include/machine/types.h @@ -11,7 +11,7 @@ #endif #define _CLOCK_T_ unsigned long /* clock() */ -#define _TIME_T_long/* time() */ +#define _TIME_T_long long /* time() */ #define _CLOCKID_T_unsigned long #define _TIMER_T_ unsigned long This is common to all newlib users. Did you mean to do that ? Yes, we all use roughly the same time. Maybe we should propose this right after the next Newlib release. -- Sebastian Huber, embedded brains GmbH Address : Dornierstr. 4, D-82178 Puchheim, Germany Phone : +49 89 189 47 41-16 Fax : +49 89 189 47 41-09 E-Mail : sebastian.hu...@embedded-brains.de PGP : Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [rtems commit] m68k: Use CPU_TIMESTAMP_USE_STRUCT_TIMESPEC
On 24/09/2014 3:51 pm, Sebastian Huber wrote: On 24/09/14 07:45, Chris Johns wrote: On 24/09/2014 3:42 pm, Sebastian Huber wrote: On 24/09/14 07:34, Chris Johns wrote: On 24/09/2014 3:27 pm, Sebastian Huber wrote: Yes, we should move to 64-bit time_t after the next release or even now. What is involved ? Something like this: diff --git a/newlib/libc/include/machine/types.h b/newlib/libc/include/machine/types.h index 40a75fa..b7265b9 100644 --- a/newlib/libc/include/machine/types.h +++ b/newlib/libc/include/machine/types.h @@ -11,7 +11,7 @@ #endif #define _CLOCK_T_ unsigned long /* clock() */ -#define _TIME_T_long/* time() */ +#define _TIME_T_long long /* time() */ #define _CLOCKID_T_unsigned long #define _TIMER_T_ unsigned long This is common to all newlib users. Did you mean to do that ? Yes, we all use roughly the same time. Maybe we should propose this right after the next Newlib release. I suspect this would be rejected in favour of keeping 32bit support and providing optional 64bit support. Small memory targets would have storage issues. Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [rtems commit] m68k: Use CPU_TIMESTAMP_USE_STRUCT_TIMESPEC
On 24/09/14 07:55, Chris Johns wrote: On 24/09/2014 3:51 pm, Sebastian Huber wrote: On 24/09/14 07:45, Chris Johns wrote: On 24/09/2014 3:42 pm, Sebastian Huber wrote: On 24/09/14 07:34, Chris Johns wrote: On 24/09/2014 3:27 pm, Sebastian Huber wrote: Yes, we should move to 64-bit time_t after the next release or even now. What is involved ? Something like this: diff --git a/newlib/libc/include/machine/types.h b/newlib/libc/include/machine/types.h index 40a75fa..b7265b9 100644 --- a/newlib/libc/include/machine/types.h +++ b/newlib/libc/include/machine/types.h @@ -11,7 +11,7 @@ #endif #define _CLOCK_T_ unsigned long /* clock() */ -#define _TIME_T_long/* time() */ +#define _TIME_T_long long /* time() */ #define _CLOCKID_T_unsigned long #define _TIMER_T_ unsigned long This is common to all newlib users. Did you mean to do that ? Yes, we all use roughly the same time. Maybe we should propose this right after the next Newlib release. I suspect this would be rejected in favour of keeping 32bit support and providing optional 64bit support. Small memory targets would have storage issues. It is easy to make this RTEMS specific, but the problem itself is not RTEMS specific. -- Sebastian Huber, embedded brains GmbH Address : Dornierstr. 4, D-82178 Puchheim, Germany Phone : +49 89 189 47 41-16 Fax : +49 89 189 47 41-09 E-Mail : sebastian.hu...@embedded-brains.de PGP : Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
