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 s...@rtems.org wrote:
Module:rtems
Branch:master
Commit:5323247c3148a22baefb1590533972c401f7d745
Changeset:
http://git.rtems.org/rtems/commit/?id=5323247c3148a22baefb1590533972c401f7d745
Author:Sebastian Huber sebastian.hu...@embedded-brains.de
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
joel.sherr...@oarcorp.com 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 s...@rtems.org
wrote:
Module:rtems
Branch:master
Commit:5323247c3148a22baefb1590533972c401f7d745
Changeset:
http://git.rtems.org/rtems/commit/?id=5323247c3148a22baefb1590533972c401f7d745
Author:Sebastian Huber sebastian.hu...@embedded-brains.de
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
joel.sherr...@oarcorp.com 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
joel.sherr...@oarcorp.com 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/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
