Hi Sandeep,
The more we discuss, I think we will get to know all sorts of CENH(as you put) are done all over the place and expecting system is work just fine even when lots of interface/contracts are broken is just .....(fill your own word :))
I promise not to discuss these CENH any further after this email :)
On Tue, Dec 10, 2019 at 03:59:01PM +0530, Sandeep Tripathy wrote:
Hi Sudeep,
On Mon, Dec 9, 2019 at 10:40 PM Sudeep Holla sudeep.holla@arm.com wrote:
The application has to terminate cleanly when SIGTERM is sent(may be using appropriate handler. And can intimate the same to the consumers so that they can consume the data before it's lost.
The DDR is not powered off ever in this scenario. So when to/how to consume the log is up to the (consumer) application design.
CENH#1
Assume its an incrementing log ie. after reboot this (producer) master again will continue to dump more records on to it.
CENH#2
(I see the roles being exchanged, OS was slave + producer and not sure what you are referring has master above. Anyways use KDUMP and features like that if you need RAM dump for portions of memory given to the kernel.
How would you suggest to handle this. In this case both producer and consumer deliberately asked for coherent memory so why it should also consider a possible data loss due to platforms not giving the coherency because it will add some time to flush the core caches.
CENH#3, not sure if such flexibility should be given to applications.
If they get non-cached(coherent) memory range they don't have to do anything isn't it ?
Applications must not try that, kernel mostly provides cached memory from it's memory allocator. I get a sense that this is some magic pre-allocated memory that is either reserved or taken out of kernel memory, but the application (along with its driver) maps it coherent in some magic way.
-- Regards, Sudeep