On Mon, 2018-11-19 at 23:09 +0100, Daniel Lezcano wrote:
> On 19/11/2018 22:53, Alexey Brodkin wrote:
> > Hi Daniel,
> >
> > On Mon, 2018-11-19 at 22:50 +0100, Daniel Lezcano wrote:
> > > On 19/11/2018 12:29, Alexey Brodkin wrote:
> > > > It turned out we used to use default implementation of sche
On 19/11/2018 22:53, Alexey Brodkin wrote:
> Hi Daniel,
>
> On Mon, 2018-11-19 at 22:50 +0100, Daniel Lezcano wrote:
>> On 19/11/2018 12:29, Alexey Brodkin wrote:
>>> It turned out we used to use default implementation of sched_clock()
>>> from kernel/sched/clock.c which was as precise as 1/HZ, i.
Hi Daniel,
On Mon, 2018-11-19 at 22:50 +0100, Daniel Lezcano wrote:
> On 19/11/2018 12:29, Alexey Brodkin wrote:
> > It turned out we used to use default implementation of sched_clock()
> > from kernel/sched/clock.c which was as precise as 1/HZ, i.e.
> > by default we had 10 msec granularity of ti
On 19/11/2018 12:29, Alexey Brodkin wrote:
> It turned out we used to use default implementation of sched_clock()
> from kernel/sched/clock.c which was as precise as 1/HZ, i.e.
> by default we had 10 msec granularity of time measurement.
>
> Now given ARC built-in timers are clocked with the same
On 11/19/18 3:30 AM, Alexey Brodkin wrote:
> It turned out we used to use default implementation of sched_clock()
> from kernel/sched/clock.c which was as precise as 1/HZ, i.e.
> by default we had 10 msec granularity of time measurement.
>
> Now given ARC built-in timers are clocked with the same f
On 19/11/2018 12:29, Alexey Brodkin wrote:
[ ... ]
> arch/arc/Kconfig| 1 +
> drivers/clocksource/Kconfig | 1 +
> drivers/clocksource/arc_timer.c | 22 ++
> 3 files changed, 24 insertions(+)
>
> diff --git a/arch/arc/Kconfig b/arch/arc/Kconfig
Can I h
It turned out we used to use default implementation of sched_clock()
from kernel/sched/clock.c which was as precise as 1/HZ, i.e.
by default we had 10 msec granularity of time measurement.
Now given ARC built-in timers are clocked with the same frequency as
CPU cores we may get much higher precisi
