Hi Peter,
On Wed, Jun 12, 2019 at 2:29 PM Peter Zijlstra wrote:
> > and the comment at the top mentions explicit sleep hooks. I wasn't
> > sure which function to use from here, though.
>
> Either local_clock() or cpu_clock(cpu). The sleep hooks are not
> something the consumer has to worry about.
Hi Thomas,
On Fri, Jun 14, 2019 at 11:50 AM Thomas Gleixner wrote:
> jiffies64 uses a seqcount on 32bit as well.
Right, but not 64-bit, which is some sort of improvement I suppose.
> Hrm, I'm not a great fan of these shortcuts which cut corners based on
> 'somewhat rarely, so it should not matt
Jason,
On Fri, 14 Jun 2019, Jason A. Donenfeld wrote:
> Hey Thomas,
>
> > --- a/kernel/time/timekeeping.c
> > +++ b/kernel/time/timekeeping.c
> > } while (read_seqcount_retry(&tk_core.seq, seq));
> >
> > - return base;
> > -
> > + return base + nsecs;
>
> The rest of the fil
Hey Thomas,
> --- a/kernel/time/timekeeping.c
> +++ b/kernel/time/timekeeping.c
> } while (read_seqcount_retry(&tk_core.seq, seq));
>
> - return base;
> -
> + return base + nsecs;
The rest of the file seems to use `ktime_add_ns(base, nsecs)`. I
realize, of course, that these d
On Thu, 13 Jun 2019, Jason A. Donenfeld wrote:
> On Thu, Jun 13, 2019 at 6:26 PM Thomas Gleixner wrote:
> > That does not make sense. The coarse time getters use
> > tk->tkr_mono.base. base is updated every tick (or if the machine is
> > completely idle right when the first CPU wakes up again).
>
Or in case that's not clear enough:
int __init mod_init(void)
{
u64 j1 = 0, j2, k1 = 0, k2, l1 = 0, l2;
for (;;) {
j2 = jiffies64_to_nsecs(get_jiffies_64());
k2 = ktime_get_coarse_boottime();
l2 = local_clock();
pr_err("%llu %llu %llu\n", j2 - j1, k2 - k1, l2 - l1);
j1 = j2
On Thu, Jun 13, 2019 at 6:26 PM Thomas Gleixner wrote:
> That does not make sense. The coarse time getters use
> tk->tkr_mono.base. base is updated every tick (or if the machine is
> completely idle right when the first CPU wakes up again).
Sense or not, it seems to be happening, at least on 5.2-
On Thu, 13 Jun 2019, Jason A. Donenfeld wrote:
> Hey Arnd,
>
> On Thu, Jun 13, 2019 at 5:40 PM Arnd Bergmann wrote:
> > A seqlock is a very cheap synchronization primitive, I would actually
> > guess that this is faster than most implementations of sched_clock()
> > that access a hardware registe
Hey Arnd,
On Thu, Jun 13, 2019 at 5:40 PM Arnd Bergmann wrote:
> A seqlock is a very cheap synchronization primitive, I would actually
> guess that this is faster than most implementations of sched_clock()
> that access a hardware register for reading the time.
It appears to me that ktime_get_co
On Thu, Jun 13, 2019 at 5:19 PM Jason A. Donenfeld wrote:
>
> Hey Arnd, Peter,
>
> On Wed, Jun 12, 2019 at 4:01 PM Arnd Bergmann wrote:
> > Documentation/core-api/timekeeping.rst describes the timekeeping
> > interfaces. I think what you want here is ktime_get_coarse_boottime().
> >
> > Note that
Hey Arnd, Peter,
On Wed, Jun 12, 2019 at 4:01 PM Arnd Bergmann wrote:
> Documentation/core-api/timekeeping.rst describes the timekeeping
> interfaces. I think what you want here is ktime_get_coarse_boottime().
>
> Note that "coarse" means "don't access the hardware clocksource"
> here, which is f
On Wed, Jun 12, 2019 at 7:55 PM Peter Zijlstra wrote:
> On Wed, Jun 12, 2019 at 11:44:35AM +0200, Jason A. Donenfeld wrote:
> > But there's still the
> > issue of the 32-bit wraparound on the base implementation.
>
> If an architecture doesn't provide a sched_clock(), you're on a
> seriously hand
On Wed, Jun 12, 2019 at 02:58:21PM +0200, Jason A. Donenfeld wrote:
> Hi Peter,
>
> Thanks for the explanation.
>
> On Wed, Jun 12, 2019 at 2:29 PM Peter Zijlstra wrote:
> > Either local_clock() or cpu_clock(cpu). The sleep hooks are not
> > something the consumer has to worry about.
>
> Alrigh
On Wed, Jun 12, 2019 at 11:46 AM Jason A. Donenfeld wrote:
> On Wed, Jun 12, 2019 at 11:03 AM Peter Zijlstra wrote:
> > How quasi? Do the comments in kernel/sched/clock.c look like something
> > you could use?
> >
> > As already mentioned in the other tasks, anything ktime will be
> > horrificall
Hi Peter,
Thanks for the explanation.
On Wed, Jun 12, 2019 at 2:29 PM Peter Zijlstra wrote:
> Either local_clock() or cpu_clock(cpu). The sleep hooks are not
> something the consumer has to worry about.
Alright. Just so long as it *is* tracking sleep, then that's fine. If
it isn't some importan
On Wed, Jun 12, 2019 at 02:28:43PM +0200, Peter Zijlstra wrote:
> AFAICT only: alpha, h8300, hexagon, m68knommu, nds32, nios2, openrisc
> are lacking any form of sched_clock(), the rest has it either natively
> or through sched_clock_register().
Scratch nds32, they use drivers/clocksource/timer-a
On Wed, Jun 12, 2019 at 11:44:35AM +0200, Jason A. Donenfeld wrote:
> Hey Peter,
>
> On Wed, Jun 12, 2019 at 11:03 AM Peter Zijlstra wrote:
> > How quasi? Do the comments in kernel/sched/clock.c look like something
> > you could use?
> >
> > As already mentioned in the other tasks, anything ktime
Hey Peter,
On Wed, Jun 12, 2019 at 11:03 AM Peter Zijlstra wrote:
> How quasi? Do the comments in kernel/sched/clock.c look like something
> you could use?
>
> As already mentioned in the other tasks, anything ktime will be
> horrifically crap when it ends up using the HPET, the code in
> kernel/
On Tue, Jun 11, 2019 at 11:09:20PM +0200, Thomas Gleixner wrote:
> > CPU: 1 PID: 7927 Comm: kworker/1:3 Tainted: G OE
> > 4.19.47-1-lts #1
> > Hardware name: Dell Inc. XPS 15 9570/02MJVY, BIOS 1.10.1 04/26/2019
That's a laptop, limited number of CPUs in those.
> > Workqueue: wg-cr
On Tue, Jun 11, 2019 at 11:09:20PM +0200, Thomas Gleixner wrote:
> Jason,
>
> On Fri, 7 Jun 2019, Jason A. Donenfeld wrote:
>
> Adding a few more people on cc and keeping full context.
>
> > Hey Thomas,
> >
> > After some discussions here prior about the different clocks
> > available, WireGuar
On 6/11/19 5:09 PM, Thomas Gleixner wrote:
> Jason,
>
> On Fri, 7 Jun 2019, Jason A. Donenfeld wrote:
>
> Adding a few more people on cc and keeping full context.
>
>> Hey Thomas,
>>
>> After some discussions here prior about the different clocks
>> available, WireGuard uses ktime_get_boot_fast_ns(
Jason,
On Fri, 7 Jun 2019, Jason A. Donenfeld wrote:
Adding a few more people on cc and keeping full context.
> Hey Thomas,
>
> After some discussions here prior about the different clocks
> available, WireGuard uses ktime_get_boot_fast_ns() pretty extensively.
> The requirement is for a quasi-
22 matches
Mail list logo
