[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