Hi, Greg. We've discussed this earlier. Breaking news: /proc is slow, /sys too. Always have been. Each /sys file is kind of fast, but there are so many files that lookups eat all the runtime. /proc files are bigger and thus slower. There is no way to filter information. If someone would post /proc today and said "it is 20-50-100" times slower (which is true) than existing interfraces, linux-kernel would not even laugh at him/her. > slow in what way? open/read/close is slow compared to equivalent not involving file descriptors and textual processing. > Text apis are good as everyone can handle them, Text APIs provoke inefficient software: Any noob can write for name in name_list: with open(f'/sys/kernel/slab/{name}/order') as f: slab_order = int(f.read().split()[0]) See the problem? It's inefficient. No open("/sys", O_DIRECTORY|O_PATH); No openat(sys_fd, "kernel/slab", O_DIRECTORY|O_PATH); No openat(sys_kernel_slab, buf, O_RDONLY); buf is allocated dynamically many times probably, it's Python after all. buf is longer than necessary. pathname buf won't be reused for result. .split() conses a list, only to discard everything but first element. Internally, sysfs allocates 1 page, instead of putting 1 byte somewhere in userspace memory. /proc too. Lookup is done every time (I don't think sysfs caches dentries in dcache but I may be mistaken, so lookup is even slower). Multiply by many times monitoring daemons run this (potentially disturbing other tasks). > ioctls are harder for obvious reasons. What? ioctl are hard now? Text APIs are garbage. If it's some crap in debugfs then noone cares. But /proc/*/maps is not in debugfs. Specifically on /proc/*/maps: * _very_ well written software know that unescaping needs to be done on pathname * (deleted) and (unreachable) junk. readlink and /proc/*/maps don't have space for flags for unambigious deleted/unreachable status which doesn't eat into pathname -- whoops > I don't understand, is this a bug in the current files? If so, why not > just fix that up? open/read DO NOT accept file-specific flags, they are dumb like that. In theory /proc/*/maps _could_ accept pread(fd, buf, sizeof(buf), addr); and return data for VMA containing "addr", but it can't because "addr" is offset in textual file. Such offset is not interesting at all. > And again "efficient" need to be quantified. * roll eyes * > Some people find text easier to handle for programmatic use :) Some people should be barred from writing software by Programming Supreme Court or something like that.