Petr Mladek <pmladek@xxxxxxxx> writes: > On Tue 2020-08-11 12:40:22, Orson Zhai wrote: >> This is an updated version which comes from patch [1] written by Thomas >> and suggestion [2] about VMCORE_INFO given by Linus. All of that want's to be properly distangled into seperate patches. >> This patch has been tested in qemu-x86-system. One problem is the timestamp >> in kernel log will be printed [ 0.000000] for longer time than before. > > This would be a regression. People put huge effort into having early boot > timestamps, see > https://lore.kernel.org/lkml/20180719205545.16512-1-pasha.tatashin@xxxxxxxxxx/ > Adding some active people from this patchset into CC. > > I wonder if we could have these early timestamps also in the mono > clock. Not really. timekeeping init happens way after the early TSC (or whatever clock) is registered as sched_clock(). And there is no realistic way to move timekeeping init earlier. What we could do instead is to utilize sched_clock() up to the point where timekeeping becomes available and ensure that monotonic time is not jumping backwards vs. sched_clock() when switching over. For this early boot phase, clock realtime timestamps would be invalid of course and they can stay invalid even after timekeeping is initialized on systems where the RTC is not available in the early boot process. > 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? Thanks, tglx _______________________________________________ kexec mailing list kexec@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/kexec
