Dne Po 3. z??? 2012 05:42:33 Atsushi Kumagai napsal(a): > Hello Petr, > > On Tue, 28 Aug 2012 19:49:49 +0200 > > Petr Tesarik <ptesarik at suse.cz> wrote: > > Add a simple cache for pages read from the dumpfile. > > > > This is a big win if we read consecutive data from one page, e.g. > > page descriptors, or even page table entries. > > > > Note that makedumpfile now always reads a complete page. This was already > > the case with kdump-compressed and sadump formats, but makedumpfile was > > throwing most of the data away. For the kdump-compressed case, we may > > actually save a lot of decompression, too. > > > > I tried to keep the cache small to minimize memory footprint, but it > > should be big enough to hold all pages to do 4-level paging plus some > > data. This is needed e.g. for vmalloc areas or Xen page frame table > > data, which are not contiguous in physical memory. > > > > Signed-off-by: Petr Tesarik <ptesarik at suse.cz> > > It's interesting to me. I want to know how performance will be improved > with this patch, so do you have speed measurements ? Not really. I only measured the hit/miss ratio, and with filtering Xen domU and dump level 0, I got the following on a small system (2G RAM): cache hit: 1818880 cache miss: 1873 The improvement isn't much for non-Xen case, because the hits are mostly due to virtual-to-physical translations, and most of Linux data is stored at virtual addresses that can be resolved by adding/subtracting a fixed offset. Of course, you will also win only the syscall overhead, because Linux keeps the data in the kernel pagecache anyway. I'll measure the times for you on a reasonably large system (~256G) and send the results here. Regards, Petr Tesarik SUSE Linux
