No need to invent new error codes here, simply
use ERR_PTR/IS_ERR_OR_NULL and such.
Signed-off-by: Cyrill Gorcunov <gorcunov@openvz.org>
Acked-by: Andrew Vagin <avagin@parallels.com>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
The restore times look like
Before patch:
futex: 370 3.554482 (84.2%)
umount: 41 0.234796 (5.6%)
read: 4737 0.113987 (2.7%)
recvmsg: 43 0.100083 (2.4%)
wait4: 10 0.033344 (0.8%)
After patch:
futex: 187 1.547642 (72.9%)
umount: 41 0.234595 (11.0%)
recvmsg: 43 0.075738 (3.6%)
flock: 42 0.038696 (1.8%)
clone: 35 0.037699 (1.8%)
Most of the time we wait for other processes to restore,
but that's OK (would only affect parallel restore). And
we see that read-s really go away (onto 7th position).
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
Acked-by: Cyrill Gorcunov <gorcunov@openvz.org>
Dump times (top-5) look like
Before patch:
writev: 1595 0.048337 (15.1%)
openat: 1326 0.041976 (13.1%)
close: 1434 0.034661 (10.8%)
read: 988 0.028760 (9.0%)
wait4: 170 0.028271 (8.8%)
After patch:
openat: 1326 0.040010 (16.4%)
close: 1434 0.030039 (12.3%)
read: 988 0.025827 (10.6%)
wait4: 170 0.025549 (10.5%)
ptrace: 834 0.021624 (8.9%)
So write-s go away from top list (turn into 8th position).
Funny thing is that all object writes get merged with the
magic writes, so the total amount of write()-s (not writev-s)
in the strace remain intact :)
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
Acked-by: Cyrill Gorcunov <gorcunov@openvz.org>
For reads and writes the names pos and bleft will
have strange meaning, so rename them into smth more
appropriate.
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
Acked-by: Cyrill Gorcunov <gorcunov@openvz.org>
I plan to re-use the bfd engine for images buffering. Right
now this engine uses one buffer that gets reused by all
bfdopen()-s. This works for current usage (one-by-pne proc
files access), but for images we'll need more buffers.
So this patch just puts buffers in a list and organizes a
stupid R-R with refill on it.
v2:
Check for buffer allocation errors
Print buffer mem pointer in debug
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
Acked-by: Andrew Vagin <avagin@parallels.com>
Currently this optimization skips unscanned data
and doesn't work. Lets skip scanned data only.
Reported-by: Jenkins
Signed-off-by: Andrey Vagin <avagin@openvz.org>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
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: Pavel Emelyanov <xemul@parallels.com>
