What glibc does (opening /proc/stat) is rather stupid, but i think your syscall
I don't think it has any other choice today. So if anything is "stupid"
it is the kernel for not providing efficient interfaces for this.
Note that these are mostly constant or semi-constant values that are updated
very rarely:
That's not true. Most of them are dynamic. Take a look at the patch.
Also several of those have changed recently.
If glibc is stupid and reads /proc/stat to receive something it could cache or
mmap() itself then hey, did you consider fixing glibc or creating a sane libc?
Caching doesn't help when you have a workload that exec()s a lot.
Also some of these values can change at runtime.
If we *really* want to offer kernel help for these values even then your
solution is still wrong: then the proper solution would be to define a standard
*data* structure and map it as a vsyscall *data* page - essentially a
kernel-guaranteed data mmap(), with no extra syscall needed!
That's quite complicted because several of those are dynamically computed
based on other values. Sometimes they are also not tied to the mm_struct -- like
the vsyscall is. For example some of the rlimits are per task, not VM.
Basically your proposal doesn't interact well with clone().
Even if we ignored that semantic problem it would need another writable page
per task because the values cannot be shared.
Also I never liked the idea of having more writable pages per task,
It increases the memory footprint of a single process more. Given a 4K
page is not a lot, but lots of 4K pages add up. Some workloads like
to have lots of small processes and I think that's a valuable use
case Linux should stay lean and efficient at.
[OK in theory one could do COW for the page and share it but that would
get really complicated]
I also don't think it's THAT performance critical to justify the vsyscall.
The simple syscall is already orders of magnitude faster than /proc, and
seems to solve the performance problems we've seen completely.
It's also simple and straight forward and simple to userstand and maintain.
I doubt any of that would apply to a vsyscall solution.
I don't think the additional effort for a vsyscall would be worth
it at this point, unless there's some concrete example that would
justify it. Even then it wouldn't work for some of the values.