Skip to content

C
criu
Switch branch/tag
  1. 23 Sep, 2014 7 commits
    • Pavel Emelyanov's avatar
      bfd: File-descriptors based buffered read · 53771adc
      Pavel Emelyanov authored 
      This sounds strange, but we kinda need one. Here's the
justification for that.

We heavily open /proc/pid/foo files. To speed things up we
do pid_dir = open("/proc/pid") then openat(pid_dir, foo).
This really saves time on big trees, up to 10%.

Sometimes we need line-by-line scan of these files, and for
that we currently use the fdopen() call. It takes a file
descriptor (obtained with openat from above) and wraps one
into a FILE*.

The problem with the latter is that fdopen _always_ mmap()s
a buffer for reads and this buffer always (!) gets unmapped
back on fclose(). This pair of mmap() + munmap() eats time
on big trees, up to 10% in my experiments with p.haul tests.

The situation is made even worse by the fact that each fgets
on the file results in a new page allocated in the kernel
(since the mapping is new). And also this fgets copies data,
which is not big deal, but for e.g. smaps file this results
in ~8K bytes being just copied around.

Having said that, here's a small but fast way of reading a
descriptor line-by-line using big buffer for reducing the
amount of read()s.

After all per-task fopen_proc()-s get reworked on this engine
(next 4 patches) the results on p.haul test would be

        Syscall     Calls      Time (% of time)
Now:
           mmap:      463  0.012033 (3.2%)
         munmap:      447  0.014473 (3.9%)
Patched:
         munmap:       57  0.002106 (0.6%)
           mmap:       74  0.002286 (0.7%)

The amount of read()s and open()s doesn't change since FILE*
also uses page-sized buffer for reading.

Also this eliminates some amount of lseek()s and fstat()s
the fdopen() does every time to catch up with file position
and to determine what sort of buffering it should use (for
terminals it's \n-driven, for files it's not).
Signed-off-by: 's avatarPavel Emelyanov <xemul@parallels.com>
      53771adc
    • Pavel's avatar
      ns: Dump namespaces in parallel · b30f0f01
      Pavel authored 
      The main reason for this is -- dumping namespace has a lot of
points when the process just waits for something. At the same
time criu process wait for the ns dumper and doesn't dump
others.

The great example of waiting for something is setns syscall.
Very often it calls synchronize_rcu() which can be quite long.
Let other processes do smth useful while this.
Signed-off-by: 's avatarPavel Emelyanov <xemul@parallels.com>
Acked-by: 's avatarAndrew Vagin <avagin@parallels.com>
      b30f0f01
    • Tycho Andersen's avatar
      remap: don't add remaps for a dead pid more than once · bbe3f941
      Tycho Andersen authored 
      Unless we seek and re-read the PB images, the only way I can see to do this is
to keep a list of the previously seen dead pids and check if a new remap is in
that list.
Signed-off-by: 's avatarTycho Andersen <tycho.andersen@canonical.com>
Signed-off-by: 's avatarPavel Emelyanov <xemul@parallels.com>
      bbe3f941
    • Tycho Andersen's avatar
      remap: don't try to remap other files in /proc · 80c4e86e
      Tycho Andersen authored 
      We can't remap these files correctly anyway, so we should just return success
if we find one of these files to remap.

v2: don't try to remap accessible files in /proc
Signed-off-by: 's avatarTycho Andersen <tycho.andersen@canonical.com>
Signed-off-by: 's avatarPavel Emelyanov <xemul@parallels.com>
      80c4e86e
    • Pavel's avatar
      mnt: Shorten the mntns dumping loop · 867bcd21
      Pavel authored 
      We currently have all mouninfo-s from all mnt namespaces collected
in one big list. On dump we scan through it to find the namespaces
we need to dump.

This can be optimized by walking the list of namespaces instead.
Signed-off-by: 's avatarPavel Emelyanov <xemul@parallels.com>
Acked-by: 's avatarAndrew Vagin <avagin@parallels.com>
      867bcd21
    • Andrey Vagin's avatar
      x86: don't call wait4 as waitpid · 6382ed43
      Andrey Vagin authored 
      Fix compilation on ARM:
pie/restorer.c: In function ‘wait_helpers’:
pie/restorer.c:728:3: error: implicit declaration of function ‘sys_waitpid’ [-Werror=implicit-function-declaration]
cc1: all warnings being treated as errors

Reported-by: Mr Jenkins
Signed-off-by: 's avatarAndrey Vagin <avagin@openvz.org>
Signed-off-by: 's avatarPavel Emelyanov <xemul@parallels.com>
      6382ed43
    • Pavel Emelyanov's avatar
      ptrace: Factor out pie stopping code · ab50f6ac
      Pavel Emelyanov authored 
      Signed-off-by: 's avatarPavel Emelyanov <xemul@parallels.com>
Acked-by: 's avatarAndrey Vagin <avagin@parallels.com>
      ab50f6ac
  3. 22 Sep, 2014 7 commits
  5. 19 Sep, 2014 12 commits
  7. 18 Sep, 2014 13 commits
  9. 16 Sep, 2014 1 commit