... which are limited by RLIMIT.
This was extremely useful for me when I looked at the pipebuf limits bugs.
[No manpages ATM, will write after feedback on the interfaces. Overall, it is trivial and clear IMO].
Differential D46747
getrlimitusage(2): a syscall and a tool to query current resource usage kib on Sep 22 2024, 1:11 PM. Authored by Tags None Referenced Files
Details
... which are limited by RLIMIT. This was extremely useful for me when I looked at the pipebuf limits bugs. [No manpages ATM, will write after feedback on the interfaces. Overall, it is trivial and clear IMO].
Diff Detail
Event TimelineComment Actions IMO it would be better to add this to procstat rlimit output, rather than adding a new utility. Why not implement this interface with a sysctl, similar to sysctl_kern_proc_rlimit()? Comment Actions This is somewhat ortogonal. The syscall is supposed to be used by the process itself to query its usage of the resources. Same as getrlimit(2) queries the limit, despite the presence of sysctl. For instance, this syscall might finally give the answer to question how much usable anon memory can be allocated, assuming the limits are enforced. Comment Actions But it takes a PID as a parameter. Having a simple syscall interface is nice I suppose, IMO it is nice to follow the precedent of:
Comment Actions Remove pid from the syscall args. Any advice how to properly use libxo would be appreciated.
Comment Actions The code looks ok to me. I didn't try testing it yet (I am away from home right now), but will try it within a day.
Comment Actions In some inline comments, I refer to a proposed diff. Here it is, to be applied in addition to this revision's diff:
Comment Actions The kernel bits look ok to me.
Comment Actions To @olce I did considered doing the separate switches to ref proc or vmspace before the operation. I rejected it because it doubles the amount of code for non-perf critical syscall. Similarly I considered doing a table of case attributes, like I did for procctl(2), and decided that it is not worth it for the same reason. Really, this should be as compact as straightforward as possible, not micro-optimized. Comment Actions I'm not suggesting to micro-optimize, except for the proc lock as it is used for lots (too many?) things already. I'm instead suggesting to separate different cases that have different requirements and to factorize boilerplate code. In the current version, e.g., you have to test whether vm == NULL for each case where vm must be used. By separating cases where vm is needed from those where ui is, you can apply boilerplate code (alloc, checks, dealloc) once and for all and simplify control flow. This also has the (nice) side effect that you then don't need to lookup ui when it is vm that is needed. The only drawback doing this is duplicating the case XXX: in two switches. But then it is almost instantaneous to grasp what is going on and why the code is globally correct (then, we can concentrate on each particular case's specific code). With the current state, both are intermingled, boilerplate code is duplicated, and we have to check more carefully for control flow. This function is not *that* long, so I don't insist, but I'll hope you'll keep considering doing that in other cases. Comment Actions Move division out of the locks. root@r-freeb44:~ #procstat rlimitusage $$ PID RESOURCE ID USAGE 2303 cpu 0 0 2303 fsize 1 -1 2303 data 2 12288 2303 stack 3 131072 2303 core 4 -1 2303 rss 5 3649536 2303 memlock 6 0 2303 nproc 7 26 2303 nofile 8 4 2303 sbsize 9 920528 2303 vmem 10 14036992 2303 npts 11 2 2303 swap 12 71441 2303 kqueues 13 1 2303 umtx 14 0 2303 pipebuf 15 0 No idea about the 'eaten' space in the cpu line. Comment Actions I think it's rather that the other lines have an extra space. There are still two changes missing, I've highlighted them with two inline comments. With these, I think the display should be OK.
|