Messages in this thread | | | Date | Tue, 05 Jun 2012 18:50:19 +0900 | From | YOSHIDA Masanori <> | Subject | Re: [RFC PATCH 0/4 V2] introduce: livedump |
| |
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
| |