Re: [RFC PATCH 0/4 V2] introduce: livedump

[YOSHIDA Masanori <masanori.yoshida.tv@hitachi.com>]

Hi, Vivek and Peter

Thank you for your replies.

Yes, I agree that it is terrible to consume a half of memory only for
this purpose.

I think buffer size can be reduced by dumping memory to disk
on-the-fly with buffer of limited size.
However, this means that page fault(PF) handling may sleep if the
buffer is temporarily full.
It is never acceptable when PF happens in preempt_disable()ed path,
but I think size of pages updated in the path is not much.

To reduce buffer size, we can introduce two types of buffers as below;
(1)Buffer dedicated for non-preemptible path
(2)Buffer for the rest

If the first buffer is full, tracking updated pages partially fails.
To avoid this, users need to allocate enough memory for this buffer.

We don't need to care about the second buffer being full,
because PF handling can wait for space by sleeping.

Regards,
Masanori

Yokohama Research Laboratory,
Hitachi, Ltd.


On 2012/06/05 6:09, Vivek Goyal wrote:
> On Fri, May 25, 2012 at 06:12:07PM +0900, YOSHIDA Masanori wrote:
>
> [..]
>> (4) It allocates about 50% of physical RAM to store dumped pages. Currently
>>      Live Dump saves all dumped data on memory once, and after that a user
>>      becomes able to use the dumped data. Live Dump itself has no feature to
>>      save dumped data onto a disk or any other storage device.
>
> People complain when kdump reserves 128M of memory when system crashes.
> I am skeptical that reserving 50% of memory for livedumps is going to fly.
>
> Thanks
> Vivek