[CRIU] [PATCH] proc: Don't use FILE* for reading personality
Pavel Emelyanov
xemul at parallels.com
Wed Sep 17 08:10:56 PDT 2014
It turned out, that fdopen (used in fopen_proc) always maps
a 4k buffer for reads and this buffer gets unmap-ed later
on fclose.
Taking into account the amount of proc files we read (~20
per task plus one file per opened file descriptor) this
mmap+munmap result in quite a lot of useless CPU time.
E.g. for a container of 20 tasks we have 1000 calls taking
~8% of total dump time.
So lets first stop doing this for simple cases -- one line
proc files.
Signed-off-by: Pavel Emelyanov <xemul at parallels.com>
---
cr-dump.c | 24 ++++++++++--------------
1 file changed, 10 insertions(+), 14 deletions(-)
diff --git a/cr-dump.c b/cr-dump.c
index 91336e8..86b079b 100644
--- a/cr-dump.c
+++ b/cr-dump.c
@@ -579,26 +579,22 @@ err:
static int get_task_personality(pid_t pid, u32 *personality)
{
- FILE *file = NULL;
- int ret = -1;
+ int fd, ret = -1;
pr_info("Obtaining personality ... ");
- file = fopen_proc(pid, "personality");
- if (!file)
- goto err;
-
- if (!fgets(loc_buf, sizeof(loc_buf), file)) {
- pr_perror("Can't read task personality");
+ fd = open_proc(pid, "personality");
+ if (fd < 0)
goto err;
- }
- *personality = atoi(loc_buf);
- ret = 0;
+ ret = read(fd, loc_buf, sizeof(loc_buf));
+ close(fd);
+ if (ret >= 0) {
+ loc_buf[ret] = '\0';
+ *personality = atoi(loc_buf);
+ }
err:
- if (file)
- fclose(file);
return ret;
}
@@ -720,7 +716,7 @@ static int dump_task_core_all(struct pstree_item *item,
pr_info("----------------------------------------\n");
ret = get_task_personality(pid, &core->tc->personality);
- if (ret)
+ if (ret < 0)
goto err;
strncpy((char *)core->tc->comm, stat->comm, TASK_COMM_LEN);
--
1.8.4.2
More information about the CRIU
mailing list