Bill,
On 04.09.15 05:46, Bill Fischofer wrote:
The time waiting is of dubious value (and portability) in a system with
dedicated worker threads. What else are they planning to do? Is that the best
design for the application? There are valid common uses for ODP_SCHED_WAIT and
ODP_SCHED_NO_WAIT. Everything else is questionable. Periodic processing
should be done via timers that trigger events rather than by guesswork on the
part of workers.
I tend to leave it as proposed Nicolas to cover existent examples.
It cannot touch cases where timers are used, I guess.
if (ns && !cycle)
cycle = 1;
ODP_SCHED_NO_WAIT (1) like check once, so if we passed ~ 1ns we wanted to
schedule at least once.
Currently it can lead to wait forever ODP_SCHED_WAIT (0).
On Thu, Sep 3, 2015 at 1:28 AM, Ivan Khoronzhuk <ivan.khoronz...@linaro.org
<mailto:ivan.khoronz...@linaro.org>> wrote:
On 03.09.15 09:20, Nicolas Morey-Chaisemartin wrote:
On 09/02/2015 11:16 PM, Ivan Khoronzhuk wrote:
On 02.09.15 12:42, Nicolas Morey-Chaisemartin wrote:
On 08/26/2015 05:47 PM, Ivan Khoronzhuk wrote:
On 26.08.15 18:22, Stuart Haslam wrote:
On Wed, Aug 26, 2015 at 06:11:13PM +0300, Ivan
Khoronzhuk wrote:
It's needed because time resolution can be a little
more than 1ns
and in this case odp_schedule_wait_time(1) returns
0, and test
generates warn w/o reason. So increase scheduler
wait time check
from 1ns to 100ns.
It's hard to imagine time source with resolution
more than 100ns,
so every implementation can return positive value
from
odp_schedule_wait_time(). In case if resolution is
more than 100ns
it's normal to warn about it at validation stage,
The wait parameter is documented as the *minimum* time
to wait for an
event so the existing check looks OK to me.
Implementations with a lower
resolution should round up.
It defined as "minimum" time to wait for odp_schedule and
others,
for odp_schedule_wait_time() it's not defined as minimum,
it's simple
convert function.
Not shure, but any of the functions I saw in linux-generic
doesn't round ticks up.
It seems that it was decided to allow application to do it,
if needed.
But if so, we have much more to change ).
In case if you are right, linux-generic implementation
should be corrected,
as it doesn't round it up.
Thanks.
I ran into this issue with our port as our clock are < 1GHz.
So 1 ns is < 1 cycle which tends to break a few things on the
linux generic port.
I fix this particular issue like this:
uint64_t odp_schedule_wait_time(uint64_t ns)
{
uint64_t cycle = odp_time_ns_to_cycles(ns);
if(cycle == 0)
cycle = 1;
return cycle;
}
Not the nicest patch but it works.
The test should probably be changed to if(ns && !cycle) so ns=0
returns 0;
Yes.
As said Stuart it may cause collisions with ODP_SCHED_WAIT (0)
and ODP_SCHED_NO_WAIT (1)
I will correct it a little later.
I don't think the collision with ODP_SCHED_NO_WAIT is too bad. We only
fall into this case if a cycle is larger than 1 ns so waiting not waiting or
waiting less thana cycle is close to the same thing.
Maybe you are right.
--
Regards,
Ivan Khoronzhuk
_______________________________________________
lng-odp mailing list
lng-odp@lists.linaro.org <mailto:lng-odp@lists.linaro.org>
https://lists.linaro.org/mailman/listinfo/lng-odp
--
Regards,
Ivan Khoronzhuk
_______________________________________________
lng-odp mailing list
lng-odp@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/lng-odp
