On Sat, Jan 08, 2022 at 09:54:37PM +0530, Pintu Agarwal wrote: > Thank you so much for your feedback... > I had a need to get total/free/available memory in my application (on > a memory constraint system). > First I tried to parse these from /proc/meminfo but then I saw sysinfo > already provides some information, > however available field was missing. Just to get available field I > need to again do all the file operations. > > Then I saw, even the "free" command doing this redundant work. > Use sysinfo system call to get "total" and "free" memory then again > get "available" memory from /proc/meminfo. > Yet again, I see, even in kernel its reading from two different places > while populating the /proc/meminfo. > Also, I am sure there are plenty of other applications where this can > be improved with this. > Moreover, I think with this field there is not much use of other ram > fields in sysinfo. > Thus I felt a need to introduce this field to ease some operations. Thanks for explanation. > > > Don't get me wrong please but such extension really need a strong > > justification because they are part of UAPI and there is not that much > > space left in sysinfo structure. We will _have_ to live with this new > > field forever so I propose to not introduce anything new here until > > we have no other choise or parsing meminfo become a really bottleneck. > > > My guess is that this situation might exist in other places as well ? > How do we handle new field addition to existing system calls ? If there is no space left in uapi structures then we simply can't extend the syscall, since we're not allowed to break api. an option is to deprecate old interface and introduce a new one but this is a painfull procedure that's why i'm not convinced that we should extend sysinfo right now. but final decision is up to mantainers of course.
