Linux: /proc/[pid]/maps performance

[cgzones]

While doing some profiling I noticed reading /proc/[pid]/maps takes the top spot. This file is read by default due to the enabled by default check for deleted shared libraries (#595).

I tried to optimize the stream handling

diff --git a/linux/LinuxProcessList.c b/linux/LinuxProcessList.c
index 487a4df..517c9f6 100644
--- a/linux/LinuxProcessList.c
+++ b/linux/LinuxProcessList.c
@@ -582,8 +582,11 @@ static void LinuxProcessList_readMaps(LinuxProcess* process, openat_arg_t procFd
    if (calcSize)
       ht = Hashtable_new(64, true);
 
+   char internalBuf[8192];
+   setvbuf(mapsfile, internalBuf, _IOFBF, sizeof(internalBuf));
+
    char buffer[1024];
-   while (fgets(buffer, sizeof(buffer), mapsfile)) {
+   while (fgets_unlocked(buffer, sizeof(buffer), mapsfile)) {
       uint64_t map_start;
       uint64_t map_end;
       bool map_execute;

but it seems only calling the function less reduces the utilization.

I had the idea to only parse /proc/[pid]/maps if the value shared in /proc/[pid]/statm changes, but replacing a shared library on disk won't modify that.

[BenBE]

Does reading the data in large chunks and parsing ourselves work, or is the actual collection in the kernel what causes most delays?

[cgzones]

The kernel documentation mentions

Note: reading /proc/PID/maps or /proc/PID/smaps is inherently racy (consistent output can be achieved only in the single read call).

But trying to read(2) the file in one go does not work:

diff --git a/linux/LinuxProcessList.c b/linux/LinuxProcessList.c
index c4b7ebc..9d5de0f 100644
--- a/linux/LinuxProcessList.c
+++ b/linux/LinuxProcessList.c
@@ -566,6 +566,14 @@ static void LinuxProcessList_calcLibSize_helper(ATTR_UNUSED ht_key_t key, void*
    *d += v->size;
 }
 
+#define MAPS_READ_BUFFER_SIZE (1024 * 1024)
+static char* mapsReadBuffer = NULL;
+
+static void mapsReadBufferCleanup(void) {
+   free(mapsReadBuffer);
+   mapsReadBuffer = NULL;
+}
+
 static void LinuxProcessList_readMaps(LinuxProcess* process, openat_arg_t procFd, bool calcSize, bool checkDeletedLib) {
    Process* proc = (Process*)process;
 
@@ -575,12 +583,18 @@ static void LinuxProcessList_readMaps(LinuxProcess* process, openat_arg_t procFd
    if (!mapsfile)
       return;
 
+   if (mapsReadBuffer == NULL) {
+      mapsReadBuffer = xMalloc(MAPS_READ_BUFFER_SIZE);
+      atexit(mapsReadBufferCleanup);
+   }
+   setvbuf(mapsfile, mapsReadBuffer, /*_IOFBF*/ _IOLBF, MAPS_READ_BUFFER_SIZE);
+
    Hashtable* ht = NULL;
    if (calcSize)
       ht = Hashtable_new(64, true);
 
    char buffer[1024];
-   while (fgets(buffer, sizeof(buffer), mapsfile)) {
+   while (fgets_unlocked(buffer, sizeof(buffer), mapsfile)) {
       uint64_t map_start;
       uint64_t map_end;
       bool map_execute;

results in

openat(4, "maps", O_RDONLY)             = 5 <0.000007>
fcntl(5, F_GETFL)                       = 0x8000 (flags O_RDONLY|O_LARGEFILE) <0.000005>
read(5, "55fbbe50f000-55fbbe513000 r--p 0"..., 1048576) = 3981 <0.000023>
read(5, "7ffa15341000-7ffa15348000 r--s 0"..., 1048576) = 4001 <0.000022>
read(5, "7ffa154bc000-7ffa154d2000 r-xp 0"..., 1048576) = 3988 <0.000020>
read(5, "7ffa15646000-7ffa15649000 r--p 0"..., 1048576) = 4016 <0.000021>
read(5, "7ffa157f3000-7ffa157f5000 rw-p 0"..., 1048576) = 4040 <0.000020>
read(5, "7ffa1625b000-7ffa1625d000 r--p 0"..., 1048576) = 4047 <0.000021>
read(5, "7ffa163ee000-7ffa163ef000 r--p 0"..., 1048576) = 4093 <0.000021>
read(5, "7ffa165bf000-7ffa165e5000 r-xp 0"..., 1048576) = 4032 <0.000020>
read(5, "7ffa16733000-7ffa1673f000 r--p 0"..., 1048576) = 4037 <0.000021>
read(5, "7ffa16a68000-7ffa16a69000 ---p 0"..., 1048576) = 4076 <0.000021>
read(5, "7ffa16d9f000-7ffa16da9000 r--p 0"..., 1048576) = 4021 <0.000020>
read(5, "7ffa16f5d000-7ffa16f5e000 r--p 0"..., 1048576) = 4002 <0.000020>
read(5, "7ffa171ca000-7ffa171d7000 r--p 0"..., 1048576) = 4003 <0.000020>
read(5, "7ffa173dc000-7ffa173de000 r--p 0"..., 1048576) = 4052 <0.000021>
read(5, "7ffa17640000-7ffa17646000 r--p 0"..., 1048576) = 3996 <0.000020>
read(5, "7ffa17c65000-7ffa17c66000 r--p 0"..., 1048576) = 4067 <0.000020>
read(5, "7ffa19972000-7ffa19973000 rw-p 0"..., 1048576) = 4094 <0.000021>
read(5, "7ffa1a0f5000-7ffa1a106000 r--p 0"..., 1048576) = 4040 <0.000020>
read(5, "7ffa1a396000-7ffa1a397000 rw-p 0"..., 1048576) = 4059 <0.000020>
read(5, "7ffa1af11000-7ffa1af12000 r--p 0"..., 1048576) = 3998 <0.000020>
read(5, "7ffa1b731000-7ffa1b8dd000 r--p 0"..., 1048576) = 4046 <0.000020>
read(5, "7ffa1c1ca000-7ffa1c1ce000 r-xp 0"..., 1048576) = 3731 <0.000021>
read(5, "", 1048576)                    = 0 <0.000005>

There might be even a bigger problem:
Linux v3.4 added torvalds/linux@b764375
causing a quadratic complexity (https://www.suse.com/support/kb/doc/?id=000018931), fixed only in v4.5 torvalds/linux@65376df.

[BenBE]

When allocating a read buffer anyways you can ignore fgets entirely, calling read on the proper fd yourself and emulate what fgets is doing using strchr(ptr, '\n'). Advantage here being that suffix check I mentioned over in #748 could skip strnlen(buffer) and thus becoming constant time.