[lkml]   [2012]   [Jun]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [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.


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

 \ /
  Last update: 2012-06-05 12:41    [W:0.127 / U:13.288 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site