Menu
▾
▴
Re: [lkcd-devel] Comments on the memdev driver
|
From: Corey M. <mi...@ac...> - 2004-05-19 16:22:17
|
I have attached a first cut at the memdev driver. Note that you must rename the current "dump_memdev.c" to "dump_stagedmem.c" to apply this patch. This is relative to the 2.6.5 version from CVS and the stock 2.6.5 kernel with the kernel patch, netdev patch, and 2.6.5 kexec patch applied. Note that the driver sets itself up by default if it is configured. Just "kexec -l ..." and cause a dump. Once the new kernel is up, do a "dd if=/dev/dump of=dumpfile" to get the dump from the device. -Corey Suparna Bhattacharya wrote: > > >It is more like a 2 level table than a list (only the higher order map >pages are in a list). It should be possible to extend the abstraction so >user space can read from dump memdev to do the things you mention. >But simpler is always better, so I look forward to your patch when you have >it ready. > >Regards >Suparna > >Suparna Bhattacharya >Linux Technology Center >IBM Software Lab, India >Golden Towers, Airport Road, Bangalore - 560017 >Direct: 91-80-5044624, Tie-line: 92-4-3624 >E-mail: bsu...@in... > > > >|---------+--------------------------------------> >| | Corey Minyard | >| | <mi...@ac...> | >| | Sent by: | >| | lkc...@li...ur| >| | ceforge.net | >| | | >| | | >| | 05/18/2004 11:19 PM | >| | | >|---------+--------------------------------------> > >-------------------------------------------------------------------------------------------------------------------------------------| > | | > | To: Suparna Bhattacharya/India/IBM@IBMIN | > | cc: Corey Minyard <cmi...@mv...>, lkc...@li..., lkc...@li... | > | Subject: Re: [lkcd-devel] Comments on the memdev driver | > | | > | | > >-------------------------------------------------------------------------------------------------------------------------------------| > > > >Suparna Bhattacharya wrote: > > > >>Much of the complication in the memdev driver comes from trying to save an >>entire memory snapshot in memory, and to be able to write it out early >>enough during the new boot without activating filesystems to reduce the >>risk of not having gone through a full-blown reboot. The code doesn't do >>all of that right now, but that was the intention. And, dump_memdevwas >>actually designed to be able to save dump pages in high memory - the >> >> >code > > >>to reserve high memory pages during bootup needs to be completed & tested. >> >>However, I must say that if you see a way to simplify the code that would >>be pretty neat. Complexity of code in the dump path is not a good thing. >>Reserving a large chunk of memory upfront to copy the areas that would be >>overwritten by the new kernel (about 16MB on some systems), is one way to >>avoid the need for compression and mapping of pages. This seems more >>affordable in today's context that it did earlier. And indeed it would be >>useful in certain environments for userland to be able to extract the dump >>directly from memory to analyse it or transfer it over the network without >>needing disk space for an interim writeout. >> >> >> >Most of the complexity and strangeness comes from the two-stage >approach. The page management complexity is mostly required (although >it could be simplified some, I think). > >I actually had to write a new one because the staged memdev didn't meet >our needs. This is for embedded, and we may be running on systems >without a disk device. Instead, our users need to be able to save the >coredump over NFS or via a program of their own choosing to spool over a >proprietary communication system. However, you could eliminate a lot of >the complexity of the two-stage approach by just saving the coredump in >memory and having a small userland program run as /sbin/init that saves >the core. That is much more flexible and is not much different than >what you do now (except that you have to have a small ramdisk). > >I have working code for reserving high pages. My changes add a >"alloc_specific_page" to the buddy allocator to allow the page to be >reserved to be specified. I moved the page reserving call to right >after the highmem is configured; that way all the pages are free that I >need. Instead of the user specifying the page to use for the "config" >page, it always uses the last page in memory. IMHO, the less setup the >user has to do, the better. > > > >>We do have some WIP patches for kexec based dumping that attempt to do >> >> >both > > >>of these things. >> >>It would be interesting to see your rewrite of memdev. Do you keep a large >>chunk of memory reserved away all the time for purposes of dump, or do you >>use some other technique ? >> >> >> >No, I use a similar technique, although I keep the data in a tree >instead of a list. Reserving big chunks of memory is really not an option. > >I'll post the patch when I get it working. > >-Corey > > > >------------------------------------------------------- >This SF.Net email is sponsored by: SourceForge.net Broadband >Sign-up now for SourceForge Broadband and get the fastest >6.0/768 connection for only $19.95/mo for the first 3 months! >http://ads.osdn.com/?ad_id=2562&alloc_id=6184&op=click >_______________________________________________ >lkcd-devel mailing list >lkc...@li... >https://lists.sourceforge.net/lists/listinfo/lkcd-devel > > > > |