lkml.org 
[lkml]   [2016]   [Aug]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH 0/2] fs, proc: optimize smaps output formatting
From
Date
On Fri, 2016-08-19 at 12:12 +0200, Michal Hocko wrote:
> Hi,
> this is rebased on top of next-20160818. Joe has pointed out that
> meminfo is using a similar trick so I have extracted guts of what we
> have already and made it more generic to be usable for smaps as well
> (patch 1). The second patch then replaces seq_printf with seq_write
> and show_val_kb which should have smaller overhead and my measuring (in
> kvm) shows quite a nice improvements. I hope kvm is not playing tricks
> on me but I didn't get to test on a real HW.


Hi Michal.

A few comments:

For the first patch:

I think this isn't worth the expansion in object size (x86-64 defconfig)

$ size fs/proc/meminfo.o*
   text    data     bss     dec     hex filename
   2698       8       0    2706     a92 fs/proc/meminfo.o.new
   2142       8       0    2150     866 fs/proc/meminfo.o.old

Creating a new static in task_mmu would be smaller and faster code.

There are only 3 other uses of %8lu in fs/proc/task_nommu.c and
those use bytes not kB.

There are a few other likely not performance sensitive similar
uses in <arch>/mm

$ git grep -E "seq_printf.*%8lu kB" arch
arch/x86/mm/pageattr.c: seq_printf(m, "DirectMap4k:    %8lu kB\n",
arch/x86/mm/pageattr.c: seq_printf(m, "DirectMap2M:    %8lu kB\n",
arch/x86/mm/pageattr.c: seq_printf(m, "DirectMap4M:    %8lu kB\n",
arch/x86/mm/pageattr.c: seq_printf(m, "DirectMap1G:    %8lu kB\n",
arch/s390/mm/pageattr.c: seq_printf(m, "DirectMap4k:    %8lu kB\n",
arch/s390/mm/pageattr.c: seq_printf(m, "DirectMap1M:    %8lu kB\n",
arch/s390/mm/pageattr.c: seq_printf(m, "DirectMap2G:    %8lu kB\n",

For the second patch:

seq_show starts with a PAGE_SIZE buffer and if that buffer isn't
big enough, seq_show redoes the entire output done to that point
into a new buffer << 1 until the buffer is big enough to hold
the output.

So I expect this case of multiple pages / megabytes worth of smap
output (40MB in your pathological case) would be rather faster if
single_open_size was used appropriately for expected output size.

And this would definitely be faster if seq_has_overflowed() was
used somewhere in the iteration loop.

\
 
 \ /
  Last update: 2016-09-17 09:57    [W:0.103 / U:0.208 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site