Performance research - Revision history

Wenhuizhang: typo correction

2023-02-22T21:18:26Z

typo correction

2015-12-10T20:48:58Z

2015-03-19T17:56:43Z

Restore

2015-03-19T10:16:51Z

Restore

2015-03-10T15:33:58Z

2014-09-16T08:11:57Z

2014-09-15T19:21:38Z

2014-02-03T14:28:03Z

added perf info

2014-02-01T21:23:42Z

2014-01-31T17:02:37Z

@@ Line 41: / Line 41: @@
 * Reading images                  1%
-* Mapping huuge premap area       << 1%
+* Mapping huge premap area       << 1%
 * (Re-)mapping sub-areas          73%
 * Filling area with data          26%

@@ Line 49: / Line 49: @@
 * Opening filemap fd              85%
 * Maping vma                      15%
 === Staging ===

← Older revision		Revision as of 10:16, 19 March 2015
Line 50:		Line 50:
	* Maping vma 15%		* Maping vma 15%

		+	=== Staging ===
		+
		+	When restoring a single task CRIU uses [[stages of restoring]] which slows things down. Need either special-care the single task restore, or introduce fine-grained locking for such things.

	[[Category: Development]]		[[Category: Development]]

← Older revision		Revision as of 08:11, 16 September 2014
Line 37:		Line 37:

	Starting from the 2nd call, setns() calls synchronize_rcu in kernel. Result -- 4 setns are 6% of 4 tests dump time.		Starting from the 2nd call, setns() calls synchronize_rcu in kernel. Result -- 4 setns are 6% of 4 tests dump time.
		+
		+	=== fopen/fgets/fclose ===
		+
		+	On some (all?) glibcs when doing fopen, fgets, fclose glibc mmap-s and then immediatelly unmaps one anon page. The thing is that for a tree of ~20 tasks these mmaps/munmaps take up to 8% of time and most likely work on the same virtual address. Knowing how kernel works, I can say that each access to this virtual address results in fresh page allocation. Keeping this page "in cache" might save some time.

@@ Line 34: / Line 34: @@
 openat(AT_FDCWD, "/proc/$pid/map_files", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 4
-=== <code>parasite_fuxup_vdso</code> ===
+=== setns ===
-The 2nd longest routine. It takes ~ 0.07 seconds on dump.
+Starting from the 2nd call, setns() calls synchronize_rcu in kernel. Result -- 4 setns are 6% of 4 tests dump time.

← Older revision		Revision as of 21:23, 1 February 2014
Line 10:		Line 10:

	Below is the list of issues found		Below is the list of issues found
		+
		+	== Images IO ==
		+
		+	Too many write-s and read-s. Each small object issues a write/read request into file. Need to improve.

	== Dump ==		== Dump ==