From: Petr Mladek <pmladek@suse.com>
To: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Cc: Prarit Bhargava <prarit@redhat.com>,
John Ogness <john.ogness@linutronix.de>,
Orson Zhai <orson.zhai@unisoc.com>, Baoquan He <bhe@redhat.com>,
cixi.geng1@unisoc.com, Stephen Boyd <sboyd@kernel.org>,
zhang.lyra@gmail.com, Steven Sistare <steven.sistare@oracle.com>,
kexec@lists.infradead.org, linux-kernel@vger.kernel.org,
Steven Rostedt <rostedt@goodmis.org>,
Jon DeVree <nuxi@vault24.org>,
John Stultz <john.stultz@linaro.org>,
ruifeng.zhang1@unisoc.com, Orson Zhai <orsonzhai@gmail.com>,
Thomas Gleixner <tglx@linutronix.de>,
Salvatore Bonaccorso <carnil@debian.org>,
Dave Young <dyoung@redhat.com>,
Dominique Martinet <asmadeus@codewreck.org>,
Vivek Goyal <vgoyal@redhat.com>,
Pavel Tatashin <pasha.tatashin@soleen.com>
Subject: Re: [RFC PATCH] printk: Change timestamp to triplet as mono, boot and real
Date: Thu, 13 Aug 2020 12:22:58 +0200 [thread overview]
Message-ID: <20200813102258.GL12903@alley> (raw)
In-Reply-To: <20200813015500.GC2020879@jagdpanzerIV.localdomain>
On Thu 2020-08-13 10:55:00, Sergey Senozhatsky wrote:
> On (20/08/11 15:02), Petr Mladek wrote:
> > On Tue 2020-08-11 14:05:12, Thomas Gleixner wrote:
> > > Petr Mladek <pmladek@suse.com> writes:
> > > > At least "crash" tool would need an update anyway. AFAIK, it checks
> > > > the size of struct printk_log and refuses to read it when it changes.
> > > >
> > > > It means that the hack with VMCOREINFO_FIELD_OFFSET probably is not
> > > > needed because we would need to update the crashdump-related tools anyway.
> > > >
> > > > Well, the timing is good. We are about to switch the printk ring
> > > > buffer into a lockless one. It requires updating the crashdump tools
> > > > as well. We could do this at the same time. The lockless ring buffer
> > > > already is in linux-next. It is aimed for 5.10 or 5.11.
> > > ...
> > > > It would be great to synchronize all these changes changes of the
> > > > printk log buffer structures.
> > >
> > > I agree that having one update is a good thing, but pretty please can we
> > > finally make progress with this and not create yet another dependency?
> >
> > To make it clear. I definitely do not want to block lockless printk by
> > this.
> >
> > BTW: I am not 100% convinced that storing all three timestamps is
> > worth it. It increases the code complexity, metadata size. It needs
> > an interface with the userspace that has to stay backward compatible.
>
> Can we, perhaps, store those various "alternative" timestamps in dict so
> then whoever wants to read them can just parse the dict key:value pairs
> attach to each printk message?
Interesting idea. It might be a way how to add optional metadata
without breaking compatibility with crashdump tools.
Well, I have bad feeling about it. Some of the reasons might be:
+ would take more space (prefix + text vs. binary representation)
+ not reliable because dict is currently dropped when no space
+ it would make the controversial dictionary feature more important
I would prefer to solve this by storing the timestamps in the
structure with metadata.
Best Regards,
Petr
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
WARNING: multiple messages have this Message-ID (diff)
From: Petr Mladek <pmladek@suse.com>
To: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Cc: Thomas Gleixner <tglx@linutronix.de>,
Orson Zhai <orsonzhai@gmail.com>,
Prarit Bhargava <prarit@redhat.com>,
Dave Young <dyoung@redhat.com>, Baoquan He <bhe@redhat.com>,
Vivek Goyal <vgoyal@redhat.com>,
Steven Rostedt <rostedt@goodmis.org>,
John Stultz <john.stultz@linaro.org>,
Stephen Boyd <sboyd@kernel.org>,
kexec@lists.infradead.org, linux-kernel@vger.kernel.org,
zhang.lyra@gmail.com, ruifeng.zhang1@unisoc.com,
cixi.geng1@unisoc.com, Orson Zhai <orson.zhai@unisoc.com>,
Pavel Tatashin <pasha.tatashin@soleen.com>,
Steven Sistare <steven.sistare@oracle.com>,
Dominique Martinet <asmadeus@codewreck.org>,
Jon DeVree <nuxi@vault24.org>,
Salvatore Bonaccorso <carnil@debian.org>,
John Ogness <john.ogness@linutronix.de>
Subject: Re: [RFC PATCH] printk: Change timestamp to triplet as mono, boot and real
Date: Thu, 13 Aug 2020 12:22:58 +0200 [thread overview]
Message-ID: <20200813102258.GL12903@alley> (raw)
In-Reply-To: <20200813015500.GC2020879@jagdpanzerIV.localdomain>
On Thu 2020-08-13 10:55:00, Sergey Senozhatsky wrote:
> On (20/08/11 15:02), Petr Mladek wrote:
> > On Tue 2020-08-11 14:05:12, Thomas Gleixner wrote:
> > > Petr Mladek <pmladek@suse.com> writes:
> > > > At least "crash" tool would need an update anyway. AFAIK, it checks
> > > > the size of struct printk_log and refuses to read it when it changes.
> > > >
> > > > It means that the hack with VMCOREINFO_FIELD_OFFSET probably is not
> > > > needed because we would need to update the crashdump-related tools anyway.
> > > >
> > > > Well, the timing is good. We are about to switch the printk ring
> > > > buffer into a lockless one. It requires updating the crashdump tools
> > > > as well. We could do this at the same time. The lockless ring buffer
> > > > already is in linux-next. It is aimed for 5.10 or 5.11.
> > > ...
> > > > It would be great to synchronize all these changes changes of the
> > > > printk log buffer structures.
> > >
> > > I agree that having one update is a good thing, but pretty please can we
> > > finally make progress with this and not create yet another dependency?
> >
> > To make it clear. I definitely do not want to block lockless printk by
> > this.
> >
> > BTW: I am not 100% convinced that storing all three timestamps is
> > worth it. It increases the code complexity, metadata size. It needs
> > an interface with the userspace that has to stay backward compatible.
>
> Can we, perhaps, store those various "alternative" timestamps in dict so
> then whoever wants to read them can just parse the dict key:value pairs
> attach to each printk message?
Interesting idea. It might be a way how to add optional metadata
without breaking compatibility with crashdump tools.
Well, I have bad feeling about it. Some of the reasons might be:
+ would take more space (prefix + text vs. binary representation)
+ not reliable because dict is currently dropped when no space
+ it would make the controversial dictionary feature more important
I would prefer to solve this by storing the timestamps in the
structure with metadata.
Best Regards,
Petr
next prev parent reply other threads:[~2020-08-13 10:23 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-08-11 4:40 [RFC PATCH] printk: Change timestamp to triplet as mono, boot and real Orson Zhai
2020-08-11 4:40 ` Orson Zhai
2020-08-11 4:56 ` Randy Dunlap
2020-08-11 4:56 ` Randy Dunlap
2020-08-11 9:44 ` Petr Mladek
2020-08-11 9:44 ` Petr Mladek
2020-08-11 12:05 ` Thomas Gleixner
2020-08-11 12:05 ` Thomas Gleixner
2020-08-11 13:02 ` Petr Mladek
2020-08-11 13:02 ` Petr Mladek
2020-08-11 13:43 ` Prarit Bhargava
2020-08-11 13:43 ` Prarit Bhargava
2020-08-13 1:55 ` Sergey Senozhatsky
2020-08-13 1:55 ` Sergey Senozhatsky
2020-08-13 10:22 ` Petr Mladek [this message]
2020-08-13 10:22 ` Petr Mladek
2020-08-13 11:31 ` Sergey Senozhatsky
2020-08-13 11:31 ` Sergey Senozhatsky
2020-08-14 9:50 ` Petr Mladek
2020-08-14 9:50 ` Petr Mladek
2020-08-13 10:26 ` Thomas Gleixner
2020-08-13 10:26 ` Thomas Gleixner
2020-08-14 6:34 ` Dave Young
2020-08-14 6:34 ` Dave Young
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200813102258.GL12903@alley \
--to=pmladek@suse.com \
--cc=asmadeus@codewreck.org \
--cc=bhe@redhat.com \
--cc=carnil@debian.org \
--cc=cixi.geng1@unisoc.com \
--cc=dyoung@redhat.com \
--cc=john.ogness@linutronix.de \
--cc=john.stultz@linaro.org \
--cc=kexec@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=nuxi@vault24.org \
--cc=orson.zhai@unisoc.com \
--cc=orsonzhai@gmail.com \
--cc=pasha.tatashin@soleen.com \
--cc=prarit@redhat.com \
--cc=rostedt@goodmis.org \
--cc=ruifeng.zhang1@unisoc.com \
--cc=sboyd@kernel.org \
--cc=sergey.senozhatsky@gmail.com \
--cc=steven.sistare@oracle.com \
--cc=tglx@linutronix.de \
--cc=vgoyal@redhat.com \
--cc=zhang.lyra@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.