Re: [PATCH 2/5] fs/procfs: implement efficient VMA querying API for /proc/<pid>/maps

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.




[Index of Archives]     [Linux Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [NTFS 3]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [NTFS 3]     [Samba]     [Device Mapper]     [CEPH Development]

  Powered by Linux