- 19 Feb, 2014 2 commits
-
-
Tikhomirov Pavel authored
it was error if come to that point from shmem.c 388L: err = open_page_xfer(&xfer, CR_FD_SHMEM_PAGEMAP, si->shmid); Signed-off-by:
Tikhomirov Pavel <snorcht@gmail.com> Signed-off-by:
Pavel Emelyanov <xemul@parallels.com>
-
Andrey Vagin authored
The offset should point on a next entry. Cc: Pavel Tikhomirov <snorcht@gmail.com> Signed-off-by:
Andrey Vagin <avagin@openvz.org> Acked-by:
Cyrill Gorcunov <gorcunov@openvz.org> Signed-off-by:
-
- 18 Feb, 2014 12 commits
-
-
Cyrill Gorcunov authored
If area is close to TASK_SIZE limit the high address may exceed it returning error once we try to read pagemap file. So limit the high address. Signed-off-by:
-
Andrey Vagin authored
Signed-off-by:
-
Andrey Vagin authored
ID: 0 signal: 26/ (null) notify: signal/pid.5954 ClockID: 1 fscanf "%p" doesn't handle "(null)". https://bugzilla.openvz.org/show_bug.cgi?id=2894 v2: make the original scanf be %d/%s and then additionally parse the obtained string v3: don't use strstr Signed-off-by:
-
Cyrill Gorcunov authored
pagemap-cache.c: In function ‘pmc_init’: pagemap-cache.c:35:20: error: comparison of distinct pointer types lacks a cast [-Werror] pagemap-cache.c: In function ‘pmc_fill_cache’: pagemap-cache.c:72:2: error: format ‘%lx’ expects argument of type ‘long unsigned int’, but argument 3 has type ‘uint64_t’ [-Werror=format] pagemap-cache.c:72:2: error: format ‘%lx’ expects argument of type ‘long unsigned int’, but argument 4 has type ‘uint64_t’ [-Werror=format] pagemap-cache.c:72:2: error: format ‘%lu’ expects argument of type ‘long unsigned int’, but argument 5 has type ‘size_t’ [-Werror=format] pagemap-cache.c:89:3: error: format ‘%lx’ expects argument of type ‘long unsigned int’, but argument 3 has type ‘uint64_t’ [-Werror=format] pagemap-cache.c:89:3: error: format ‘%lx’ expects argument of type ‘long unsigned int’, but argument 4 has type ‘uint64_t’ [-Werror=format] pagemap-cache.c:100:4: error: format ‘%lx’ expects argument of type ‘long unsigned int’, but argument 3 has type ‘uint64_t’ [-Werror=format] pagemap-cache.c:100:4: error: format ‘%lx’ expects argument of type ‘long unsigned int’, but argument 4 has type ‘uint64_t’ [-Werror=format] pagemap-cache.c: In function ‘pmc_get_map’: pagemap-cache.c:136:3: error: format ‘%lx’ expects argument of type ‘long unsigned int’, but argument 6 has type ‘uint64_t’ [-Werror=format] pagemap-cache.c:136:3: error: format ‘%lx’ expects argument of type ‘long unsigned int’, but argument 7 has type ‘uint64_t’ [-Werror=format] Reported-by:
-
Cyrill Gorcunov authored
These are needed to compile project on CentOS 6. Signed-off-by:
-
Cyrill Gorcunov authored
- drop empty line - end ending endif comment Signed-off-by:
-
Cyrill Gorcunov authored
This improve speed if we're dumping a big set of small vmas. CentOS-6 container ------------------ Without cache dump: { freezing_time: 1705 frozen_time: 44885 memdump_time: 9064 memwrite_time: 15846 pages_scanned: 246979 pages_skipped_parent: 0 pages_written: 2831 irmap_resolve: 0 } With cache dump: { freezing_time: 898 frozen_time: 40859 memdump_time: 7254 memwrite_time: 16375 pages_scanned: 246979 pages_skipped_parent: 0 pages_written: 2831 irmap_resolve: 0 } 1024 VMA, 40K each ------------------ Without cache dump: { freezing_time: 170 frozen_time: 30372 memdump_time: 3895 memwrite_time: 691 pages_scanned: 13487 pages_skipped_parent: 0 pages_written: 61 irmap_resolve: 0 } With cache dump: { freezing_time: 231 frozen_time: 27646 memdump_time: 768 memwrite_time: 798 pages_scanned: 13487 pages_skipped_parent: 0 pages_written: 61 irmap_resolve: 0 } Signed-off-by: -
Cyrill Gorcunov authored
Pavel reported that in case if there a big number of small vmas present in the dumpee we're reading /proc/pid/pagemap too frequently. To speedup this procedue we inroduce pagemap cache. The interface is: - pmc_init/pmc_fini for cache initialization and freeing - pmc_get_map to retrieve specific PMEs array for VMA area v2: - Move internal constants to pagemap-cache.c - Make PAGEMAP_LEN to accept virtual address/size - Don't adjust low bound in caching mode to save a couple of code bytes Reported-by:
-
Christopher Covington authored
Otherwise the build can fail with the following message. ln: .../libcriu.so.1: File exists make: *** [install] Error 1 Signed-off-by:
Christopher Covington <cov@codeaurora.org> Signed-off-by:
-
Christopher Covington authored
Signed-off-by:
-
Ruslan Kuprieiev authored
Thank Vladimir Davydov <vdavidov@parallels.com> for help and config. Signed-off-by:
Ruslan Kuprieiev <kupruser@gmail.com> Acked-by:
Vladimir Davydov <vdavydov@parallels.com> Acked-by:
Kir Kolyshkin <kir@openvz.org> Signed-off-by:
-
Ruslan Kuprieiev authored
Signed-off-by:
-
- 14 Feb, 2014 6 commits
-
-
Pavel Emelyanov authored
We want to write into empty image files, so we unlink them before dumping into. Let's O_TRUNC it instead. Signed-off-by:
Andrew Vagin <avagin@parallels.com>
-
Pavel Emelyanov authored
Signed-off-by:
-
Pavel Emelyanov authored
We spend a lot of time reading the /proc/$pid/smaps file. The time is spent in two places: 1 kernel puts too many info into it 2 fgets pulls info in 1024-bytes chunks, info about one vma is typically bigger (up to 3k bytes) thus we call read() ~3 times per one vma, which increases the amount of time spent in kernel to re-fill this info Setting the internal buffer to PAGE_SIZE size reduces the amount of read()-s on ~60% during basic container dump. Setting bigger buffer doesn't work, as kernel's seq file engine feeds at most one page of data per read syscall regardless of the buffer size. Signed-off-by:
-
Andrey Vagin authored
This function splices data from a process to criu, so dump_pages describes the real meaning. Signed-off-by:
-
Andrey Vagin authored
Before this patch, criu splices all data in pipes and then saves these data in a image file. Here is a problem, becase creating pipes with big buffers fails too often, because a kernel tries to allocate a big linear chunks of memory. Now memory are dumped for a few iterations, where the size of pipe buffers is restricted. Signed-off-by:
-
Andrey Vagin authored
PIPE_MAX_SIZE is calculated according with the kernel code. PPB_IOV_BATCH has been taken from my mind. Signed-off-by:
-
- 13 Feb, 2014 1 commit
-
-
Pavel Emelyanov authored
Acked-by:
-
- 11 Feb, 2014 4 commits
-
-
Pavel Emelyanov authored
Signed-off-by: -
Pavel Emelyanov authored
This is the first time restorer gets info back from CRIU service. At that time it makes perfect sense to report what PID we're working with. Signed-off-by: -
Christopher Covington authored
This allows building with busybox sed, for example. Signed-off-by:
-
Cyrill Gorcunov authored
In commit 459828b6 I suddenly broke backward compatibility of auxv vector on 32bit machines. Bring it back. Reported-by:
-
- 10 Feb, 2014 15 commits
-
-
Pavel Emelyanov authored
We call tar, ip, iptables, etc. when restoring container. The problem is that these stuff is called from inside new mount namespace after pivot_root(). But the execvp uses PATH variable inherited from the host system, which may not reflect real binaries layout. Add "/bin" to path as temporary workaround. Signed-off-by: -
Pavel Emelyanov authored
When live-migrating a container on NFS the link-remap cannot create original file on target machine, since the file name is still visible -- source CT is alive. The proper fix would be to move file aside, then create link, then move original file back, but since NFS changes file name anyway, we just do the same -- generate another name for link. Signed-off-by: -
Andrey Vagin authored
Before this patch, criu splices all data in pipes and then saves these data in a image file. Here is a problem, becase creating pipes with big buffers fails too often, because a kernel tries to allocate a big linear chunks of memory. Now memory are dumped for a few iterations, where the size of pipe buffers is restricted. TODO: need to rework pre-dump, because currently dumping data from pipes are postponed. We are going to use sys_process_vm_readv for this. Signed-off-by: -
Andrey Vagin authored
It's preparation to dump memory by chunks. Signed-off-by:
-
Andrey Vagin authored
The problem is that vmsplice() to a big pipe fails very often. The kernel allocates a linear chunk of memory for pipe buffer descriptos, but a big allocation in kernel can fail. So we need to restrict maximal capacity of pipes. But the number of pipes is restricted too, so we need to split dumping memory on chunks. In this patch we calculates the pipe size for which vmsplice() will not fail. v2: s/batch/chunk and a few other small fixes v3: Remove callbacks from page_pipes and reuse pipes Signed-off-by:
-
Christopher Covington authored
The following issue is possibly caused by using busybox make. protobuf/packet-sock.pb-c.c: In function 'packet_sock_entry__init': protobuf/packet-sock.pb-c.c:98:3: error: this decimal constant is unsigned only in ISO C90 [-Werror] Use a belt-and-suspenders approach to ensure it doesn't happen. Signed-off-by: -
Christopher Covington authored
The current -march settings will cause an error if the user a conflicting flags such as -mcpu=cortex-a15. Use USERCFLAGS instead of CFLAGS so that a default is provided but can be overridden. Change-Id: I8ffecd6bfd7ad5794486a5d14d27bce3170898d3 Acked-by:
Alexander Kartashov <alekskartashov@parallels.com> Signed-off-by:
-
Christopher Covington authored
Ideally, a user could set CFLAGS on the command line to contain compilation options and include and library paths (or maybe set those last two with CPPFLAGS and LDFLAGS). Unfortunately, setting CFLAGS on the command line currently short-circuits essential logic in the makefile and breaks the build. After a first failed attempt it appears that a monolithic overhaul or "flag day" to fix this is a substantial undertaking, so for now just provide a workaround in the form of a USERCFLAGS variable. Signed-off-by: -
Christopher Covington authored
Perhaps left over from when a single types.h was being used for multiple architectures, remove the ARM definition of AT_VECTOR_SIZE from the x86 types.h header. Also remove the CONFIG_ARM definition since it unused. Acked-by:
-
Christopher Covington authored
The current mechanism for determining ARM architecture version breaks down when cross-compiling. Default to ARMv7 if the user specifies ARCH=arm. Users wishing to cross-compile for ARMv6 platforms such as the Raspberry Pi should use ARCH=armv6 as previously required. Acked-by:
-
Christopher Covington authored
Without this a user may encounter the following error. arch/arm/include/asm/atomic.h:38:2: error: implicit declaration of function ‘smp_mb’ With the #error pragma a user is a least pointed to the specific section in the file that's causing the problem arch/arm/include/asm/atomic.h:21:2: error: #error ARM architecture version (CONFIG_ARMV*) not set or unsupported. Acked-by:
-
Christopher Covington authored
ARCH is a user-facing variable and setting it on the command line clobbers any manipulation attempted in the makefile. Following the example of the Linux kernel makefiles, use a SRCARCH variable instead for the internal, potentially fixed-up, architecture name. This fixes the following error. make ARCH=x86_64 Makefile:69: *** "The architecture x86_64 isn't supported". Stop. Signed-off-by: -
Christopher Covington authored
The top-level makefile defines an ARCH_DIR variable. Always use it rather than referencing ARCH directly, since ARCH may be set by the user on the command line and that raw input may not be what needs to be used internally. Signed-off-by: -
Christopher Covington authored
A user may have necessary linker directories specified in CFLAGS. Make sure to include them. Change-Id: I76c2a7bd6e34cc282bfcd5f83cc69ae7fa2c8cc2 Signed-off-by: -
Christopher Covington authored
The makefile includes need to be moved for everything to be defined properly when the configure tests run. The Ubuntu 12.04 x86_64 GCC and Linaro's 13.08 and newer AArch64 GCC's have the if_packet.h kernel header, but as of 13.12, the Linaro AArch32 GCC does not. Change-Id: I363c43fdb81b028f99aac77e15bff9462c87af4b Signed-off-by:
-
