Handle mmaped regions in cache

Because all pages must go into the cache, data is unnecessarily copied from mmapped regions to cache. Avoid this copying by storing the mmapped regions directly in the cache.

First, the cache code needs a clean up clarification of the concept, especially the meaning of the pending list (allocated cache entries whose content is not yet valid).

Second, the cache must be able to handle differently sized objects so that it can store individual pages as well as mmapped regions.

Last, the cache eviction code must be extended to allow either reusing the read buffer or unmapping the region.

Changelog:
v2: cache cleanup _and_ actuall mmap implementation
v1: only the cache cleanup

Petr Tesarik (8):
cache: get rid of search loop in cache_add()
cache: allow to return a page to the pool
cache: do not allocate from the pending list
cache: add hit/miss statistics to the final report
cache: allocate buffers in one big chunk
cache: allow arbitrary size of cache entries
cache: store mapped regions directly in the cache
cleanup: remove unused page_is_fractional

 cache.c        |  81 +++++++++++++++++----------------
 cache.h        |  16 +++++--
 elf_info.c     |  16 -------
 elf_info.h     |   2 -
 makedumpfile.c | 138 ++++++++++++++++++++++++++++++++++-----------------------
 5 files changed, 138 insertions(+), 115 deletions(-)

Because all pages must go into the cache, data is unnecessarily copied from mmapped regions to cache. Avoid this copying by storing the mmapped regions directly in the cache.

First, the cache code needs a clean up clarification of the concept, especially the meaning of the pending list (allocated cache entries whose content is not yet valid).

Second, the cache must be able to handle differently sized objects so that it can store individual pages as well as mmapped regions.

Last, the cache eviction code must be extended to allow either reusing the read buffer or unmapping the region.

Changelog:
v2: cache cleanup _and_ actuall mmap implementation
v1: only the cache cleanup

Petr Tesarik (8):
cache: get rid of search loop in cache_add()
cache: allow to return a page to the pool
cache: do not allocate from the pending list
cache: add hit/miss statistics to the final report
cache: allocate buffers in one big chunk
cache: allow arbitrary size of cache entries
cache: store mapped regions directly in the cache
cleanup: remove unused page_is_fractional

 cache.c        |  81 +++++++++++++++++----------------
 cache.h        |  16 +++++--
 elf_info.c     |  16 -------
 elf_info.h     |   2 -
 makedumpfile.c | 138 ++++++++++++++++++++++++++++++++++-----------------------
 5 files changed, 138 insertions(+), 115 deletions(-)

Hello Petr,

As a conclusion, we could think of mapping larger chunks also for the fragmented case of -d 31 to reduce the amount of mmap/munmap calls.

Hello Petr,

With your patches I now used "perf record" and "perf stat" to check where the CPU time is consumed for -d31 and -d0.

For -d31 the read case is better and for -d0 the mmap case is better.

[...]

As already said, we think the reason is that for -d0 we issue only a small number of mmap/munmap calls because the mmap chunks are larger than the read chunks.

For -d31 memory is fragmented and we issue lots of small mmap/munmap calls. Because munmap (at least on s390) is a very expensive operation and we need two calls (mmap/munmap), the mmap mode is slower that the read mode.

I counted the mmap and read system calls with "perf stat":

mmap unmap read = sum
===============================================
mmap -d0 482 443 165 1090
mmap -d31 13454 13414 165 27033

  non-mmap -d0         34       3 458917   458954 
  non-mmap -d31        34       3  74273    74310

Here the actual results I got with "perf record":

$ time ./makedumpfile  -d 31 /proc/vmcore  /dev/null -f

Output of "perf report" for mmap case:

/* Most time spent for unmap in kernel */

   29.75%  makedumpfile  [kernel.kallsyms]  [k] unmap_single_vma
    9.84%  makedumpfile  [kernel.kallsyms]  [k] remap_pfn_range
    8.49%  makedumpfile  [kernel.kallsyms]  [k] vm_normal_page

/* Still some mmap overhead in makedumpfile readmem() */
21.56% makedumpfile makedumpfile [.] readmem

8.49% makedumpfile makedumpfile [.] write_kdump_pages_cyclic

Output of "perf report" for non-mmap case:

/* Time spent for sys_read (that needs also two copy operations on s390 :() */

   25.32%  makedumpfile  [kernel.kallsyms]  [k] memcpy_real
   22.74%  makedumpfile  [kernel.kallsyms]  [k] __copy_to_user

/* readmem() for read path is cheaper ? */

   13.49%  makedumpfile  makedumpfile       [.] write_kdump_pages_cyclic
    4.53%  makedumpfile  makedumpfile       [.] readmem

[...]
I hope this analysis helps more than it confuses :-)

As a conclusion, we could think of mapping larger chunks also for the fragmented case of -d 31 to reduce the amount of mmap/munmap calls.

Another open question was why the mmap case consumes more CPU time in readmem() than the read case. Our theory is that the first memory access is slower because it is not in the HW cache. For the mmap case userspace issues the first access (copy to makdumpfile cache) and for the read case the kernel issues the first access (memcpy_real/copy_to_user). Therefore the cache miss is accounted to userspace for mmap and to kernel for read.

And last but not least, perhaps on s390 we could replace the bounce buffer used for memcpy_real()/copy_to_user() by some more inteligent solution.

Quoted 8 lines

I counted the mmap and read system calls with "perf stat":

mmap unmap read = sum
===============================================
mmap -d0 482 443 165 1090
mmap -d31 13454 13414 165 27033

  non-mmap -d0         34       3 458917   458954
  non-mmap -d31        34       3  74273    74310

If your VM has 1.5 GiB of RAM, then the numbers for -d0 look reasonable. For -d31, we should be able to do better than this by allocating more cache slots and improving the algorithm. I originally didn't deem it worth the effort, but seeing almost 30 times more mmaps than with -d0 may change my mind.

Quoted 7 lines

Here the actual results I got with "perf record":

$ time ./makedumpfile  -d 31 /proc/vmcore  /dev/null -f

Output of "perf report" for mmap case:

Quoted 7 lines

/* Most time spent for unmap in kernel */

   29.75%  makedumpfile  [kernel.kallsyms]  [k] unmap_single_vma
    9.84%  makedumpfile  [kernel.kallsyms]  [k] remap_pfn_range
    8.49%  makedumpfile  [kernel.kallsyms]  [k] vm_normal_page

/* Still some mmap overhead in makedumpfile readmem() */
21.56% makedumpfile makedumpfile [.] readmem

This number is interesting. Did you compile makedumpfile with optimizations? If yes, then this number probably includes some functions which were inlined.

Quoted 11 lines

8.49% makedumpfile makedumpfile [.] write_kdump_pages_cyclic

Output of "perf report" for non-mmap case:

/* Time spent for sys_read (that needs also two copy operations on s390 :() */

   25.32%  makedumpfile  [kernel.kallsyms]  [k] memcpy_real
   22.74%  makedumpfile  [kernel.kallsyms]  [k] __copy_to_user

/* readmem() for read path is cheaper ? */

   13.49%  makedumpfile  makedumpfile       [.] write_kdump_pages_cyclic
    4.53%  makedumpfile  makedumpfile       [.] readmem

Yes, much lower overhead of readmem is strange. For a moment I suspected wrong accounting of the page fault handler, but then I realized that for /proc/vmcore, all page table entries are created with the present bit set already, so there are no page faults...

I haven't had time yet to set up a system for reproduction, but I'll try to identify what's eating up the CPU time in readmem().

Quoted 6 lines

[...]
I hope this analysis helps more than it confuses :-)

As a conclusion, we could think of mapping larger chunks also for the fragmented case of -d 31 to reduce the amount of mmap/munmap calls.

I agree in general. Memory mapped through /proc/vmcore does not increase run-time memory requirements, because it only adds a mapping to the old kernel's memory. The only limiting factor is the virtual address space. On many architectures, this is no issue at all, and we could simply map the whole file at beginning. On some architectures, the virtual address space is smaller than possible physical RAM, so this approach would not work for them.

Quoted 8 lines

Another open question was why the mmap case consumes more CPU time in readmem() than the read case. Our theory is that the first memory access is slower because it is not in the HW cache. For the mmap case userspace issues the first access (copy to makdumpfile cache) and for the read case the kernel issues the first access (memcpy_real/copy_to_user). Therefore the cache miss is accounted to userspace for mmap and to kernel for read.

I have no idea how to measure this on s390. On x86_64 I would add some asm code to read TSC before and after the memory access instruction. I guess there is a similar counter on s390. Suggestions?

Quoted 3 lines

And last but not least, perhaps on s390 we could replace the bounce buffer used for memcpy_real()/copy_to_user() by some more inteligent solution.

Which would then improve the non-mmap times even more, right?

Petr T

Hello,

(Note: my email address has changed.)

In x86_64, calling ioremap/iounmap per page in copy_oldmem_page() causes big performance degradation, so mmap() was introduced on /proc/vmcore. However, there is no big difference between read() and mmap() in s390 since it doesn't need ioremap/iounmap in copy_oldmem_page(), so other issues have been revealed, right?

[...]

Quoted 9 lines

Quoted 8 lines

I counted the mmap and read system calls with "perf stat":

mmap unmap read = sum
===============================================
mmap -d0 482 443 165 1090
mmap -d31 13454 13414 165 27033

  non-mmap -d0         34       3 458917   458954
  non-mmap -d31        34       3  74273    74310

Quoted 5 lines

If your VM has 1.5 GiB of RAM, then the numbers for -d0 look reasonable. For -d31, we should be able to do better than this by allocating more cache slots and improving the algorithm. I originally didn't deem it worth the effort, but seeing almost 30 times more mmaps than with -d0 may change my mind.

Are you going to do it as v3 patch?

I'm going to release v1.5.8 soon, so I'll adopt v2 patch if you don't think updating it.

Thanks
Atsushi Kumagai

Quoted 77 lines

Quoted 7 lines

Here the actual results I got with "perf record":

$ time ./makedumpfile  -d 31 /proc/vmcore  /dev/null -f

Output of "perf report" for mmap case:

Quoted 7 lines

/* Most time spent for unmap in kernel */

   29.75%  makedumpfile  [kernel.kallsyms]  [k] unmap_single_vma
    9.84%  makedumpfile  [kernel.kallsyms]  [k] remap_pfn_range
    8.49%  makedumpfile  [kernel.kallsyms]  [k] vm_normal_page

/* Still some mmap overhead in makedumpfile readmem() */
21.56% makedumpfile makedumpfile [.] readmem

This number is interesting. Did you compile makedumpfile with optimizations? If yes, then this number probably includes some functions which were inlined.

Quoted 6 lines

8.49% makedumpfile makedumpfile [.]
write_kdump_pages_cyclic

Output of "perf report" for non-mmap case:

   /* Time spent for sys_read (that needs also two copy operations

Quoted 8 lines

on s390 :() */ 25.32% makedumpfile [kernel.kallsyms] [k] memcpy_real 22.74% makedumpfile [kernel.kallsyms] [k] __copy_to_user

/* readmem() for read path is cheaper ? */
13.49% makedumpfile makedumpfile [.]
write_kdump_pages_cyclic 4.53% makedumpfile makedumpfile [.] readmem

Yes, much lower overhead of readmem is strange. For a moment I suspected wrong accounting of the page fault handler, but then I realized that for /proc/vmcore, all page table entries are created with the present bit set already, so there are no page faults...

I haven't had time yet to set up a system for reproduction, but I'll try to identify what's eating up the CPU time in readmem().

Quoted 6 lines

[...]
I hope this analysis helps more than it confuses :-)

As a conclusion, we could think of mapping larger chunks also for the fragmented case of -d 31 to reduce the amount of mmap/munmap calls.

I agree in general. Memory mapped through /proc/vmcore does not increase run-time memory requirements, because it only adds a mapping to the old kernel's memory. The only limiting factor is the virtual address space. On many architectures, this is no issue at all, and we could simply map the whole file at beginning. On some architectures, the virtual address space is smaller than possible physical RAM, so this approach would not work for them.

Quoted 8 lines

Another open question was why the mmap case consumes more CPU time in readmem() than the read case. Our theory is that the first memory access is slower because it is not in the HW cache. For the mmap case userspace issues the first access (copy to makdumpfile cache) and for the read case the kernel issues the first access (memcpy_real/copy_to_user). Therefore the cache miss is accounted to userspace for mmap and to kernel for read.

I have no idea how to measure this on s390. On x86_64 I would add some asm code to read TSC before and after the memory access instruction. I guess there is a similar counter on s390. Suggestions?

Quoted 3 lines

And last but not least, perhaps on s390 we could replace the bounce buffer used for memcpy_real()/copy_to_user() by some more inteligent solution.

Which would then improve the non-mmap times even more, right?

Petr T

Quoted 21 lines · On Fri, 13 Mar 2015 04:10:22 +0000 Atsushi Kumagai <[email protected]>…

Hello,

(Note: my email address has changed.)

In x86_64, calling ioremap/iounmap per page in copy_oldmem_page() causes big performance degradation, so mmap() was introduced on /proc/vmcore. However, there is no big difference between read() and mmap() in s390 since it doesn't need ioremap/iounmap in copy_oldmem_page(), so other issues have been revealed, right?

[...]

Quoted 9 lines

Quoted 8 lines

I counted the mmap and read system calls with "perf stat":

mmap unmap read = sum
===============================================
mmap -d0 482 443 165 1090
mmap -d31 13454 13414 165 27033

  non-mmap -d0         34       3 458917   458954
  non-mmap -d31        34       3  74273    74310

Quoted 7 lines

Quoted 5 lines

If your VM has 1.5 GiB of RAM, then the numbers for -d0 look reasonable. For -d31, we should be able to do better than this by allocating more cache slots and improving the algorithm. I originally didn't deem it worth the effort, but seeing almost 30 times more mmaps than with -d0 may change my mind.

Are you going to do it as v3 patch?

No. Tuning the caching algorithm requires a lot of research. I plan to do it, but testing it with all scenarios (and tuning the algorithm based on the results) will probably take weeks. I don't think it makes sense to wait for it.

Quoted 2 lines

I'm going to release v1.5.8 soon, so I'll adopt v2 patch if you don't think updating it.

Since v2 already brings some performance gain, I appreciate it if you can adopt it for v1.5.8.

Thank you very much,
Petr Tesarik

Quoted 80 lines

Thanks
Atsushi Kumagai

Quoted 77 lines

Quoted 7 lines

Here the actual results I got with "perf record":

$ time ./makedumpfile  -d 31 /proc/vmcore  /dev/null -f

Output of "perf report" for mmap case:

Quoted 7 lines

/* Most time spent for unmap in kernel */

   29.75%  makedumpfile  [kernel.kallsyms]  [k] unmap_single_vma
    9.84%  makedumpfile  [kernel.kallsyms]  [k] remap_pfn_range
    8.49%  makedumpfile  [kernel.kallsyms]  [k] vm_normal_page

/* Still some mmap overhead in makedumpfile readmem() */
21.56% makedumpfile makedumpfile [.] readmem

This number is interesting. Did you compile makedumpfile with optimizations? If yes, then this number probably includes some functions which were inlined.

Quoted 6 lines

8.49% makedumpfile makedumpfile [.]
write_kdump_pages_cyclic

Output of "perf report" for non-mmap case:

   /* Time spent for sys_read (that needs also two copy operations

Quoted 8 lines

on s390 :() */ 25.32% makedumpfile [kernel.kallsyms] [k] memcpy_real 22.74% makedumpfile [kernel.kallsyms] [k] __copy_to_user

/* readmem() for read path is cheaper ? */
13.49% makedumpfile makedumpfile [.]
write_kdump_pages_cyclic 4.53% makedumpfile makedumpfile [.] readmem

Yes, much lower overhead of readmem is strange. For a moment I suspected wrong accounting of the page fault handler, but then I realized that for /proc/vmcore, all page table entries are created with the present bit set already, so there are no page faults...

I haven't had time yet to set up a system for reproduction, but I'll try to identify what's eating up the CPU time in readmem().

Quoted 6 lines

[...]
I hope this analysis helps more than it confuses :-)

As a conclusion, we could think of mapping larger chunks also for the fragmented case of -d 31 to reduce the amount of mmap/munmap calls.

I agree in general. Memory mapped through /proc/vmcore does not increase run-time memory requirements, because it only adds a mapping to the old kernel's memory. The only limiting factor is the virtual address space. On many architectures, this is no issue at all, and we could simply map the whole file at beginning. On some architectures, the virtual address space is smaller than possible physical RAM, so this approach would not work for them.

Quoted 8 lines

Another open question was why the mmap case consumes more CPU time in readmem() than the read case. Our theory is that the first memory access is slower because it is not in the HW cache. For the mmap case userspace issues the first access (copy to makdumpfile cache) and for the read case the kernel issues the first access (memcpy_real/copy_to_user). Therefore the cache miss is accounted to userspace for mmap and to kernel for read.

I have no idea how to measure this on s390. On x86_64 I would add some asm code to read TSC before and after the memory access instruction. I guess there is a similar counter on s390. Suggestions?

Quoted 3 lines

And last but not least, perhaps on s390 we could replace the bounce buffer used for memcpy_real()/copy_to_user() by some more inteligent solution.

Which would then improve the non-mmap times even more, right?

Petr T

Quoted 2 lines

On Fri, 13 Mar 2015 04:10:22 +0000
Atsushi Kumagai <[email protected]> wrote:

[...]

Quoted 5 lines

Quoted 2 lines

I'm going to release v1.5.8 soon, so I'll adopt v2 patch if you don't think updating it.

Since v2 already brings some performance gain, I appreciate it if you can adopt it for v1.5.8.

Ok, but unfortunately I got some error log during my test like below:

  $ ./makedumpfile -d31 /tmp/vmcore ./dumpfile.d31
  Excluding free pages               : [  0.0 %] /
  reset_bitmap_of_free_pages: The free list is broken.
  reset_bitmap_of_free_pages: The free list is broken.

makedumpfile Failed.
$

All of errors are the same as the above at least in my test. I clarified that [PATCH v2 7/8] causes this by git bisect, but the root cause is under investigation.

Quoted 82 lines

Thank you very much,
Petr Tesarik

Quoted 79 lines

Thanks
Atsushi Kumagai

Quoted 76 lines

Quoted 7 lines

Here the actual results I got with "perf record":

$ time ./makedumpfile  -d 31 /proc/vmcore  /dev/null -f

Output of "perf report" for mmap case:

Quoted 7 lines

/* Most time spent for unmap in kernel */

   29.75%  makedumpfile  [kernel.kallsyms]  [k] unmap_single_vma
    9.84%  makedumpfile  [kernel.kallsyms]  [k] remap_pfn_range
    8.49%  makedumpfile  [kernel.kallsyms]  [k] vm_normal_page

/* Still some mmap overhead in makedumpfile readmem() */
21.56% makedumpfile makedumpfile [.] readmem

This number is interesting. Did you compile makedumpfile with optimizations? If yes, then this number probably includes some functions which were inlined.

Quoted 6 lines

8.49% makedumpfile makedumpfile [.]
write_kdump_pages_cyclic

Output of "perf report" for non-mmap case:

   /* Time spent for sys_read (that needs also two copy

Quoted 8 lines

operations on s390 :() */ 25.32% makedumpfile [kernel.kallsyms] [k] memcpy_real 22.74% makedumpfile [kernel.kallsyms] [k] __copy_to_user

/* readmem() for read path is cheaper ? */
13.49% makedumpfile makedumpfile [.]
write_kdump_pages_cyclic 4.53% makedumpfile makedumpfile [.] readmem

Yes, much lower overhead of readmem is strange. For a moment I suspected wrong accounting of the page fault handler, but then I realized that for /proc/vmcore, all page table entries are created with the present bit set already, so there are no page faults...

I haven't had time yet to set up a system for reproduction, but I'll try to identify what's eating up the CPU time in readmem().

Quoted 6 lines

[...]
I hope this analysis helps more than it confuses :-)

As a conclusion, we could think of mapping larger chunks also for the fragmented case of -d 31 to reduce the amount of mmap/munmap calls.

I agree in general. Memory mapped through /proc/vmcore does not increase run-time memory requirements, because it only adds a mapping to the old kernel's memory. The only limiting factor is the virtual address space. On many architectures, this is no issue at all, and we could simply map the whole file at beginning. On some architectures, the virtual address space is smaller than possible physical RAM, so this approach would not work for them.

Quoted 8 lines

Another open question was why the mmap case consumes more CPU time in readmem() than the read case. Our theory is that the first memory access is slower because it is not in the HW cache. For the mmap case userspace issues the first access (copy to makdumpfile cache) and for the read case the kernel issues the first access (memcpy_real/copy_to_user). Therefore the cache miss is accounted to userspace for mmap and to kernel for read.

I have no idea how to measure this on s390. On x86_64 I would add some asm code to read TSC before and after the memory access instruction. I guess there is a similar counter on s390. Suggestions?

Quoted 3 lines

And last but not least, perhaps on s390 we could replace the bounce buffer used for memcpy_real()/copy_to_user() by some more inteligent solution.

Quoted 3 lines

Quoted 3 lines

Quoted 3 lines

Which would then improve the non-mmap times even more, right?

Petr T

_______________________________________________
kexec mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/kexec

Quoted 16 lines · On Mon, 16 Mar 2015 05:14:25 +0000 Atsushi Kumagai <[email protected]>…

Quoted 2 lines

On Fri, 13 Mar 2015 04:10:22 +0000
Atsushi Kumagai <[email protected]> wrote:

[...]

Quoted 5 lines

Quoted 2 lines

I'm going to release v1.5.8 soon, so I'll adopt v2 patch if you don't think updating it.

Since v2 already brings some performance gain, I appreciate it if you can adopt it for v1.5.8.

Ok, but unfortunately I got some error log during my test like below:

  $ ./makedumpfile -d31 /tmp/vmcore ./dumpfile.d31
  Excluding free pages               : [  0.0 %] /
  reset_bitmap_of_free_pages: The free list is broken.
  reset_bitmap_of_free_pages: The free list is broken.

Quoted 6 lines

makedumpfile Failed.
$

All of errors are the same as the above at least in my test. I clarified that [PATCH v2 7/8] causes this by git bisect, but the root cause is under investigation.

The only change I can think of is the removal of page_is_fractional. Originally, LOADs that do not start on a page boundary were never mmapped. With this patch, this check is removed.

Can you try adding the following check to mappage_elf (and dropping patch 8/8)?

	if (page_is_fractional(offset))
		return NULL;

Petr T

P.S. This reminds me I should try to get some kernel dumps with fractional pages for regression testing...

Quoted 90 lines

Quoted 85 lines

Thank you very much,
Petr Tesarik

Quoted 82 lines

Thanks
Atsushi Kumagai

Quoted 79 lines

Quoted 7 lines

Here the actual results I got with "perf record":

$ time ./makedumpfile  -d 31 /proc/vmcore  /dev/null -f

Output of "perf report" for mmap case:

Quoted 7 lines

/* Most time spent for unmap in kernel */

   29.75%  makedumpfile  [kernel.kallsyms]  [k] unmap_single_vma
    9.84%  makedumpfile  [kernel.kallsyms]  [k] remap_pfn_range
    8.49%  makedumpfile  [kernel.kallsyms]  [k] vm_normal_page

/* Still some mmap overhead in makedumpfile readmem() */
21.56% makedumpfile makedumpfile [.] readmem

This number is interesting. Did you compile makedumpfile with optimizations? If yes, then this number probably includes some functions which were inlined.

Quoted 6 lines

8.49% makedumpfile makedumpfile [.]
write_kdump_pages_cyclic

Output of "perf report" for non-mmap case:

   /* Time spent for sys_read (that needs also two copy

Quoted 8 lines

operations on s390 :() */ 25.32% makedumpfile [kernel.kallsyms] [k] memcpy_real 22.74% makedumpfile [kernel.kallsyms] [k] __copy_to_user

/* readmem() for read path is cheaper ? */
13.49% makedumpfile makedumpfile [.]
write_kdump_pages_cyclic 4.53% makedumpfile makedumpfile [.] readmem

Yes, much lower overhead of readmem is strange. For a moment I suspected wrong accounting of the page fault handler, but then I realized that for /proc/vmcore, all page table entries are created with the present bit set already, so there are no page faults...

I haven't had time yet to set up a system for reproduction, but I'll try to identify what's eating up the CPU time in readmem().

Quoted 6 lines

[...]
I hope this analysis helps more than it confuses :-)

As a conclusion, we could think of mapping larger chunks also for the fragmented case of -d 31 to reduce the amount of mmap/munmap calls.

I agree in general. Memory mapped through /proc/vmcore does not increase run-time memory requirements, because it only adds a mapping to the old kernel's memory. The only limiting factor is the virtual address space. On many architectures, this is no issue at all, and we could simply map the whole file at beginning. On some architectures, the virtual address space is smaller than possible physical RAM, so this approach would not work for them.

Quoted 8 lines

Another open question was why the mmap case consumes more CPU time in readmem() than the read case. Our theory is that the first memory access is slower because it is not in the HW cache. For the mmap case userspace issues the first access (copy to makdumpfile cache) and for the read case the kernel issues the first access (memcpy_real/copy_to_user). Therefore the cache miss is accounted to userspace for mmap and to kernel for read.

I have no idea how to measure this on s390. On x86_64 I would add some asm code to read TSC before and after the memory access instruction. I guess there is a similar counter on s390. Suggestions?

Quoted 3 lines

And last but not least, perhaps on s390 we could replace the bounce buffer used for memcpy_real()/copy_to_user() by some more inteligent solution.

Which would then improve the non-mmap times even more, right?

Petr T

_______________________________________________
kexec mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/kexec

Quoted 33 lines

Quoted 16 lines · On Mon, 16 Mar 2015 05:14:25 +0000 Atsushi Kumagai <[email protected]>…

Quoted 2 lines

On Fri, 13 Mar 2015 04:10:22 +0000
Atsushi Kumagai <[email protected]> wrote:

[...]

Quoted 5 lines

Quoted 2 lines

I'm going to release v1.5.8 soon, so I'll adopt v2 patch if you don't think updating it.

Since v2 already brings some performance gain, I appreciate it if you can adopt it for v1.5.8.

Ok, but unfortunately I got some error log during my test like below:

  $ ./makedumpfile -d31 /tmp/vmcore ./dumpfile.d31
  Excluding free pages               : [  0.0 %] /
  reset_bitmap_of_free_pages: The free list is broken.
  reset_bitmap_of_free_pages: The free list is broken.

Quoted 6 lines

makedumpfile Failed.
$

All of errors are the same as the above at least in my test. I clarified that [PATCH v2 7/8] causes this by git bisect, but the root cause is under investigation.

The only change I can think of is the removal of page_is_fractional. Originally, LOADs that do not start on a page boundary were never mmapped. With this patch, this check is removed.

Can you try adding the following check to mappage_elf (and dropping patch 8/8)?

Quoted 2 lines

	if (page_is_fractional(offset))
		return NULL;

It worked, thanks!

Additionally, I've remembered that we should keep page_is_fractional() for old kernels.

https://lkml.org/lkml/2013/11/13/439

Thanks
Atsushi Kumagai

Quoted 98 lines

Petr T

P.S. This reminds me I should try to get some kernel dumps with fractional pages for regression testing...

Quoted 93 lines

Quoted 88 lines

Thank you very much,
Petr Tesarik

Quoted 85 lines

Thanks
Atsushi Kumagai

Quoted 82 lines

Quoted 7 lines

Here the actual results I got with "perf record":

$ time ./makedumpfile  -d 31 /proc/vmcore  /dev/null -f

Output of "perf report" for mmap case:

Quoted 8 lines

/* Most time spent for unmap in kernel */ 29.75% makedumpfile [kernel.kallsyms] [k]
unmap_single_vma 9.84% makedumpfile [kernel.kallsyms] [k] remap_pfn_range 8.49% makedumpfile [kernel.kallsyms] [k] vm_normal_page

/* Still some mmap overhead in makedumpfile readmem() */
21.56% makedumpfile makedumpfile [.] readmem

This number is interesting. Did you compile makedumpfile with optimizations? If yes, then this number probably includes some functions which were inlined.

Quoted 6 lines

8.49% makedumpfile makedumpfile [.]
write_kdump_pages_cyclic

Output of "perf report" for non-mmap case:

   /* Time spent for sys_read (that needs also two copy

Quoted 8 lines

operations on s390 :() */ 25.32% makedumpfile [kernel.kallsyms] [k] memcpy_real 22.74% makedumpfile [kernel.kallsyms] [k] __copy_to_user

/* readmem() for read path is cheaper ? */
13.49% makedumpfile makedumpfile [.]
write_kdump_pages_cyclic 4.53% makedumpfile makedumpfile [.] readmem

Yes, much lower overhead of readmem is strange. For a moment I suspected wrong accounting of the page fault handler, but then I realized that for /proc/vmcore, all page table entries are created with the present bit set already, so there are no page faults...

I haven't had time yet to set up a system for reproduction, but I'll try to identify what's eating up the CPU time in readmem().

Quoted 6 lines

[...]
I hope this analysis helps more than it confuses :-)

As a conclusion, we could think of mapping larger chunks also for the fragmented case of -d 31 to reduce the amount of mmap/munmap calls.

I agree in general. Memory mapped through /proc/vmcore does not increase run-time memory requirements, because it only adds a mapping to the old kernel's memory. The only limiting factor is the virtual address space. On many architectures, this is no issue at all, and we could simply map the whole file at beginning. On some architectures, the virtual address space is smaller than possible physical RAM, so this approach would not work for them.

Quoted 8 lines

Another open question was why the mmap case consumes more CPU time in readmem() than the read case. Our theory is that the first memory access is slower because it is not in the HW cache. For the mmap case userspace issues the first access (copy to makdumpfile cache) and for the read case the kernel issues the first access (memcpy_real/copy_to_user). Therefore the cache miss is accounted to userspace for mmap and to kernel for read.

I have no idea how to measure this on s390. On x86_64 I would add some asm code to read TSC before and after the memory access instruction. I guess there is a similar counter on s390. Suggestions?

Quoted 3 lines

And last but not least, perhaps on s390 we could replace the bounce buffer used for memcpy_real()/copy_to_user() by some more inteligent solution.

Which would then improve the non-mmap times even more, right?

Petr T

_______________________________________________
kexec mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/kexec

On Mon, 9 Mar 2015 17:08:58 +0100
Michael Holzheu <[email protected]> wrote:

Quoted 8 lines

I counted the mmap and read system calls with "perf stat":

mmap unmap read = sum
===============================================
mmap -d0 482 443 165 1090
mmap -d31 13454 13414 165 27033

  non-mmap -d0         34       3 458917   458954 
  non-mmap -d31        34       3  74273    74310

If your VM has 1.5 GiB of RAM, then the numbers for -d0 look reasonable.

For -d31, we should be able to do better than this
by allocating more cache slots and improving the algorithm. I originally didn't deem it worth the effort, but seeing almost 30 times more mmaps than with -d0 may change my mind.

Quoted 12 lines

Here the actual results I got with "perf record":

$ time ./makedumpfile  -d 31 /proc/vmcore  /dev/null -f

Output of "perf report" for mmap case:

/* Most time spent for unmap in kernel */

   29.75%  makedumpfile  [kernel.kallsyms]  [k] unmap_single_vma
    9.84%  makedumpfile  [kernel.kallsyms]  [k] remap_pfn_range
    8.49%  makedumpfile  [kernel.kallsyms]  [k] vm_normal_page

Quoted 2 lines

/* Still some mmap overhead in makedumpfile readmem() */
21.56% makedumpfile makedumpfile [.] readmem

This number is interesting. Did you compile makedumpfile with optimizations? If yes, then this number probably includes some functions which were inlined.

Quoted 8 lines

8.49% makedumpfile makedumpfile [.] write_kdump_pages_cyclic

Output of "perf report" for non-mmap case:

   /* Time spent for sys_read (that needs also two copy operations on s390 :() */
   25.32%  makedumpfile  [kernel.kallsyms]  [k] memcpy_real
   22.74%  makedumpfile  [kernel.kallsyms]  [k] __copy_to_user

Quoted 3 lines

/* readmem() for read path is cheaper ? */

   13.49%  makedumpfile  makedumpfile       [.] write_kdump_pages_cyclic
    4.53%  makedumpfile  makedumpfile       [.] readmem

Yes, much lower overhead of readmem is strange. For a moment I suspected wrong accounting of the page fault handler, but then I realized that for /proc/vmcore, all page table entries are created with the present bit set already, so there are no page faults...

I haven't had time yet to set up a system for reproduction, but I'll try to identify what's eating up the CPU time in readmem().

Quoted 3 lines

[...]
I hope this analysis helps more than it confuses :-)

Quoted 3 lines

As a conclusion, we could think of mapping larger chunks also for the fragmented case of -d 31 to reduce the amount of mmap/munmap calls.

I agree in general. Memory mapped through /proc/vmcore does not increase run-time memory requirements, because it only adds a mapping to the old kernel's memory.

The only limiting factor is the virtual
address space. On many architectures, this is no issue at all, and we could simply map the whole file at beginning. On some architectures, the virtual address space is smaller than possible physical RAM, so this approach would not work for them.

Quoted 8 lines

Another open question was why the mmap case consumes more CPU time in readmem() than the read case. Our theory is that the first memory access is slower because it is not in the HW cache. For the mmap case userspace issues the first access (copy to makdumpfile cache) and for the read case the kernel issues the first access (memcpy_real/copy_to_user). Therefore the cache miss is accounted to userspace for mmap and to kernel for read.

I have no idea how to measure this on s390. On x86_64 I would add some asm code to read TSC before and after the memory access instruction. I guess there is a similar counter on s390. Suggestions?

Quoted 4 lines

And last but not least, perhaps on s390 we could replace the bounce buffer used for memcpy_real()/copy_to_user() by some more inteligent solution.

Which would then improve the non-mmap times even more, right?