Hello Petr,
With your patch we get 5-10 percent performance improvement on s390.
Two examples:
$ time ./makedumpfile -d 31 /proc/vmcore /dev/null -f
user sys = total
=====================================
With patches 0.156 0.248 0.404
Without patches 0.168 0.274 0.442 <- No idea why we save system time?
$ time ./makedumpfile -d 0 /proc/vmcore /dev/null -f
user sys = total
=====================================
With patches 0.683 0.020 0.703
Without patches 0.714 0.019 0.733
Regards
Michael
On Fri, 6 Mar 2015 15:03:12 +0100
Petr Tesarik <ptesarik at suse.cz> wrote:
> 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(-)
>
