----- Original Message ----- > From: "Kirill A. Shutemov" <kirill@xxxxxxxxxxxxx> > To: "Mathieu Desnoyers" <mathieu.desnoyers@xxxxxxxxxxxx> > Cc: "Matthew Wilcox" <willy@xxxxxxxxxxxxxxx>, "Ross Zwisler" <ross.zwisler@xxxxxxxxxxxxxxx>, "lttng-dev" > <lttng-dev@xxxxxxxxxxxxxxx>, linux-fsdevel@xxxxxxxxxxxxxxx, linux-mm@xxxxxxxxx, linux-kernel@xxxxxxxxxxxxxxx > Sent: Tuesday, October 28, 2014 6:54:58 AM > Subject: Re: Progress on system crash traces with LTTng using DAX and pmem > > On Sat, Oct 25, 2014 at 12:51:25PM +0000, Mathieu Desnoyers wrote: > > FYI, the main reason why my customer wants to go with a > > "trace into memory that survives soft reboot" approach > > rather than to use things like kexec/kdump is that they > > care about the amount of time it takes to reboot their > > machines. They want a solution where they can extract the > > detailed crash data after reboot, after the machine is > > back online, rather than requiring a few minutes of offline > > time to extract the crash details. > > IIRC, on x86 there's no guarantee that your memory content will be > preserved over reboot. BIOS is free to mess with it. Hi Kirill, This is a good point, There are a few more aspects to consider here: - Other architectures appear to have different guarantees, for instance ARM which, AFAIK, does not reset memory on soft reboot (well at least for my customer's boards). So I guess if x86 wants to be competitive, it would be good for them to offer a similar feature, - Already having a subset of machines supporting this is useful, e.g. storing trace buffers and recovering them after a crash, - Since we are in a world of dynamically upgradable BIOS, perhaps if we can show that there is value in having a BIOS option to specify a memory range that should not be reset on soft reboot, BIOS vendors might be inclined to include an option for it, - Perhaps UEFI BIOS already have some way of specifying that a memory range should not be reset on soft reboot ? Thoughts ? Thanks, Mathieu -- Mathieu Desnoyers EfficiOS Inc. http://www.efficios.com -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
