On Mon, 29 Jan 2018, Mark Salyzyn wrote:
> Any movement on the following proposal? tglx@ do you have an update?
This sits in my inbox since then due to the melted spectrum mess
Any movement on the following proposal? tglx@ do you have an update?
-- Mark
On 11/14/2017 02:50 PM, Thomas Gleixner wrote:
On Tue, 14 Nov 2017, Linus Torvalds wrote:
I'd suggest simply adding another time to the internal 'struct
printk_log' (and probably just set it in "log_store()").
Doesn'
On Sun, Nov 19, 2017 at 8:20 PM, Kevin Easton wrote:
>
> As a comment from the userspace peanut gallery, I personally hope this
> does pass muster. The existing POSIX wording implies that MONOTONIC
> doesn't stop counting over suspend, and that's what you need when you
> want to know the time ela
On Sat, Nov 18, 2017 at 01:26:07AM +0100, Thomas Gleixner wrote:
> On Thu, 16 Nov 2017, Thomas Gleixner wrote:
> > I hope that I can find a few spare cycles to whip up a POC patch which does
> > not make stuff fall apart immediately.
>
> Here you go. It survived suspend resume in a VM.
>
> Thanks
On Fri, 17 Nov 2017, Linus Torvalds wrote:
> On Fri, Nov 17, 2017 at 4:26 PM, Thomas Gleixner wrote:
> >
> > Here you go. It survived suspend resume in a VM.
>
> That looks almost too small.
>
> If this were to allow us to basically unify BOOTTIME/MONOTONIC, that
> would be lovely.
I surely mis
On Fri, Nov 17, 2017 at 4:26 PM, Thomas Gleixner wrote:
>
> Here you go. It survived suspend resume in a VM.
That looks almost too small.
If this were to allow us to basically unify BOOTTIME/MONOTONIC, that
would be lovely.
Should we just try it, with the understanding that we'll quite
possibly
On Thu, 16 Nov 2017, Thomas Gleixner wrote:
> I hope that I can find a few spare cycles to whip up a POC patch which does
> not make stuff fall apart immediately.
Here you go. It survived suspend resume in a VM.
Thanks,
tglx
8<
Subject: timekeeping: Make monotoni
On Wed, 15 Nov 2017, Linus Torvalds wrote:
> On Wed, Nov 15, 2017 at 4:37 PM, Thomas Gleixner wrote:
> >
> > This broke stuff because the historic behaviour was to not advance on
> > resume and the change caused massive timer expiries right after resume
> > which confused the hell out of things, b
On Wed, Nov 15, 2017 at 4:37 PM, Thomas Gleixner wrote:
>
> This broke stuff because the historic behaviour was to not advance on
> resume and the change caused massive timer expiries right after resume
> which confused the hell out of things, because timers fired immediately
> which were not expe
On Wed, Nov 15, 2017 at 4:37 PM, Thomas Gleixner wrote:
> On Wed, 15 Nov 2017, Linus Torvalds wrote:
>>
>> So I agree with all of this, but I wonder what actuall yuses that
>> BOOTTIME to make it worth even synchronizing with.
>>
>> I'm assuming it's some evdev user.
>>
>> But I'm wondering if per
On Wed, 15 Nov 2017, Linus Torvalds wrote:
>
> So I agree with all of this, but I wonder what actuall yuses that
> BOOTTIME to make it worth even synchronizing with.
>
> I'm assuming it's some evdev user.
>
> But I'm wondering if perhaps we could just simplify our own lives and
> make CLOCK_BOOT
On Wed, Nov 15, 2017 at 8:26 AM, Mark Salyzyn wrote:
>
> Maybe for completeness, but having it may straighten out a synchronization
> mess.
>
> [TL;DR]
>
> "If you have three watches, you will never know what time it is"(tm)
>
> Android peripherals with embedded firmware (camera, sensor hub, etc)
On 11/14/2017 04:00 PM, Linus Torvalds wrote:
On Tue, Nov 14, 2017 at 2:50 PM, Thomas Gleixner wrote:
+/*
+ * struct timestanps - Simultaneous mono/boot/real timestamps
+ * @mono: Monotonic timestamp
+ * @boot: Boottime timestamp
+ * @real: Realtime timestamp
+ */
Side note: doe
* Linus Torvalds wrote:
> On Tue, Nov 14, 2017 at 2:50 PM, Thomas Gleixner wrote:
> > +/*
> > + * struct timestanps - Simultaneous mono/boot/real timestamps
> > + * @mono: Monotonic timestamp
> > + * @boot: Boottime timestamp
> > + * @real: Realtime timestamp
> > + */
>
> Side n
Hello Mark,
On (11/14/17 07:56), Mark Salyzyn wrote:
[..]
> Thanks for the vote of confidence :-) but we were holding back re spinning
> that set until the ability to switch the primary timestamp got accepted. (we
> were to use U suffix for realtime, B for boottime etc to designate them).
>
> Pri
On Tue, Nov 14, 2017 at 2:50 PM, Thomas Gleixner wrote:
> +/*
> + * struct timestanps - Simultaneous mono/boot/real timestamps
> + * @mono: Monotonic timestamp
> + * @boot: Boottime timestamp
> + * @real: Realtime timestamp
> + */
Side note: does anybody really wanr/need the bootti
On Tue, 14 Nov 2017, Linus Torvalds wrote:
> On Tue, Nov 14, 2017 at 3:04 PM, Thomas Gleixner wrote:
> > True. I already replaced all of them except this one:
> >
> > @@ -1022,6 +1026,7 @@ void log_buf_vmcoreinfo_setup(void)
> > */
> > VMCOREINFO_STRUCT_SIZE(printk_log);
> >
On Tue, Nov 14, 2017 at 3:04 PM, Thomas Gleixner wrote:
> True. I already replaced all of them except this one:
>
> @@ -1022,6 +1026,7 @@ void log_buf_vmcoreinfo_setup(void)
> */
> VMCOREINFO_STRUCT_SIZE(printk_log);
> VMCOREINFO_OFFSET(printk_log, ts_nsec);
> + VMCO
On Tue, 14 Nov 2017, Linus Torvalds wrote:
> On Tue, Nov 14, 2017 at 2:50 PM, Thomas Gleixner wrote:
> >
> > Something like the untested patch below should do the storage and converts
> > the primary timestamp from local_clock() to clock monotonic.
>
> This may work.
>
> > - u64 ts_nsec;
On Tue, Nov 14, 2017 at 2:50 PM, Thomas Gleixner wrote:
>
> Something like the untested patch below should do the storage and converts
> the primary timestamp from local_clock() to clock monotonic.
This may work.
> - u64 ts_nsec;/* timestamp in nanoseconds */
> + /* Time
On Tue, 2017-11-14 at 23:50 +0100, Thomas Gleixner wrote:
> Something like the untested patch below should do the storage and converts
> the primary timestamp from local_clock() to clock monotonic.
trivia:
> --- a/kernel/printk/printk.c
> +++ b/kernel/printk/printk.c
> @@ -352,7 +352,11 @@ enum l
n Tue, 14 Nov 2017, Linus Torvalds wrote:
> On Tue, Nov 14, 2017 at 2:10 PM, Mark Salyzyn wrote:
> > On 11/14/2017 01:29 PM, Linus Torvalds wrote:
> >>
> >> And then maybe you can send a single patch that changes *ONLY*
> >> print_time(), with an explanation of how Android uses
> >> CONFIG_PRINTK_
On Tue, Nov 14, 2017 at 2:10 PM, Mark Salyzyn wrote:
> On 11/14/2017 01:29 PM, Linus Torvalds wrote:
>>
>> And then maybe you can send a single patch that changes *ONLY*
>> print_time(), with an explanation of how Android uses
>> CONFIG_PRINTK_TIME and would like that to be realtime instead of the
On 11/14/2017 01:29 PM, Linus Torvalds wrote:
And then maybe you can send a single patch that changes *ONLY*
print_time(), with an explanation of how Android uses
CONFIG_PRINTK_TIME and would like that to be realtime instead of the
monotonic clock that we traditionally use.
I would be pleased to
On Tue, Nov 14, 2017 at 1:16 PM, Mark Salyzyn wrote:
>
> User is _root_ (assuming default perms for nodes), not some random user.
Totally irrelevant.
It was clear from this discussion that the developers involved in the
discussion APPARENTLY DID NOT EVEN UNDERSTAND the linkage to systemd,
for ex
On 11/14/2017 01:07 PM, Linus Torvalds wrote:
But all of this is entirely separate from the "changing from one clock
that has small issues for good reasons to FOUR DIFFERENT CLOCKS THAT
THE USER CHOOSES RANDOMLY".
User is _root_ (assuming default perms for nodes), not some random user.
At leas
On Tue, 14 Nov 2017, Linus Torvalds wrote:
> On Tue, Nov 14, 2017 at 12:21 PM, Thomas Gleixner wrote:
> >
> > First of all sched_clock() and CLOCK_MONOTONIC can drift apart frequency
> > wise pretty bad.
>
> Yes. And I would actuall ynot object to just making the printk buffers
> use CLOCK_MONOTO
On Tue, Nov 14, 2017 at 12:21 PM, Thomas Gleixner wrote:
>
> First of all sched_clock() and CLOCK_MONOTONIC can drift apart frequency
> wise pretty bad.
Yes. And I would actuall ynot object to just making the printk buffers
use CLOCK_MONOTONIC.
The reason we avoided that was we didn't want to ta
On Tue, 14 Nov 2017, Linus Torvalds wrote:
>
> But that really means that you can't just change what "ts_nsec" means
> - it's exported as "microseconds since boot".
That's true if sched clock is stable and high resolution and does not stop
during suspend.
So in reality this clock has random meani
On Tue, Nov 14, 2017 at 2:03 AM, Petr Mladek wrote:
>
> AFAIK, local clock is not synchronous between different machines
> and even CPUs on the same machine. It was used in printk() because
> it was lockless. Therefore it is kind of random itself.
It's not that it would be synchronous between mac
On 11/14/2017 02:03 AM, Petr Mladek wrote:
On Mon 2017-11-13 17:18:33, Linus Torvalds wrote:
On Mon, Nov 13, 2017 at 1:36 AM, Thomas Gleixner wrote:
Honestly, this just seems bogus to me, particularly since it's a single choice.
The *sane* model would be to
(a) continue to use the existing
On 11/14/2017 05:03 AM, Petr Mladek wrote:
> On Mon 2017-11-13 17:18:33, Linus Torvalds wrote:
>> On Mon, Nov 13, 2017 at 1:36 AM, Thomas Gleixner wrote:
>>> Linus,
>>>
>>> please pull the latest core-printk-for-linus git tree from:
>>>
>>>git://git.kernel.org/pub/scm/linux/kernel/git/tip/ti
On Mon 2017-11-13 17:18:33, Linus Torvalds wrote:
> On Mon, Nov 13, 2017 at 1:36 AM, Thomas Gleixner wrote:
> > Linus,
> >
> > please pull the latest core-printk-for-linus git tree from:
> >
> >git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
> > core-printk-for-linus
> >
> > This up
On Mon, Nov 13, 2017 at 5:18 PM, Linus Torvalds
wrote:
>
> (b) just emit a "synchronization printk" every once in a while, which
> is obviously also using the same standard time source, but the line
> actually _says_ what the other time sources are.
Side note: there's a few good obvious times to
On Mon, Nov 13, 2017 at 1:36 AM, Thomas Gleixner wrote:
> Linus,
>
> please pull the latest core-printk-for-linus git tree from:
>
>git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
> core-printk-for-linus
>
> This update adds the mechanisms to emit printk timestamps based on
> differ
Linus,
please pull the latest core-printk-for-linus git tree from:
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
core-printk-for-linus
This update adds the mechanisms to emit printk timestamps based on
different clocks:
- scheduler clock (default)
- monotonic time
- boot t
36 matches
Mail list logo
