Merge common parts of process walker and connection walker

[2opremio]

After #961 they are both going through /proc/PID/fd/* . See #812 (comment)

[schu]

I read over the code and don't see any obvious common parts between the two walkers:

While both do fs.ReadDirNames(path.Join(w.procRoot, filename, "fd")), pidWalker already uses the given CachingWalker to gather the namespace info (i.e. the data is already available). In walkNamespace, fs.ReadDirNames is used very specifically to associate sockets with processes.

Am I missing something?

[alban]

probe/process/walker_linux.go calls ReadDirNames but it actually doesn't care about the names and only reports the number of files:

  openFiles, err := fs.ReadDirNames(path.Join(w.procRoot, filename, "fd"))
...
  OpenFilesCount: len(openFiles),

ReadDirNames calls syscall.Getdents and syscall.ParseDirent. The parsing and string allocations could be optimized since we don't care about the names.

I don't think that would change the performances much, but we could try.

[alban]

With readdirnames.go, I ran 2000 iterations over /proc/*/fd/:

• 12s using Golang's ReadDirNames
• 8.6s using my new implementation without parsing the filenames, just counting the entries

The code takes a couple of assumptions on procfs:

1. Linux always generates the "." and ".." directories.
2. procfs' getdents does not returns missing files with inode=0

That's a 28% gain on my laptop with 340 processes running. It's better than I thought. I don't know how much it would help Scope (Scope does not do that many iterations over /proc/*/fd). And that would be more code to maintain.

/cc @ekimekim