[rtems commit] m68k: Use CPU_TIMESTAMP_USE_STRUCT_TIMESPEC
Chris Johns
chrisj at rtems.org
Wed Sep 24 05:34:17 UTC 2014
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.sherrill at 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_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.
>
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
More information about the devel
mailing list