In this blog post, Oracle Linux kernel developer Rahul Yadav discusses a few details about version 2 of his libresource project.
As discussed in my previous blog[1] on libresource, we are working on a library which provides APIs to get system resource information for user-land applications. The system resource information includes information related to memory, networking, devices and various other statistics.
Currently an application developer needs to read this information mostly from procfs and sysfs. The developer needs to open a file, read the desired information, parse that information and then close the file. libresource provides simple APIs to do away with all these steps and allow the application to get the information via one call.
In version 1 of libresource we delivered the following:
- Basic infrastructure so adding new resource information is straightforward
- We added a lot of memory and networking related system resource information
- All the user application facing APIs are done
I presented the current status at Linux Plumbers Conference 2018[2] and discussed with the community on what we should be doing next in libresource version 2. The following things came out of that discussion:
- We need to add more system resource information in the library. A large application like a database or web servers need a lot of system related information to take decisions, and it will be good for them to get all system resource information from one library. We are planning to add the following:
| Resource Id | Description |
|---|---|
| NET_TCPSENDBUFSIZE | Send buffer sizes for TCP |
| NET_TCPRECVBUFSIZ | recv buffer sizes for TCP |
| NET_GLOBALSENDBUFSIZE | Send buffer sizes for global |
| NET_GLOBALRECVBUFSIZE | Global recv buffer sizes |
| NET_BUFSIZEINFOALL | Send/recv buffer sizes for global and TCP |
| MMAP_PROC_HEAPINFO | Heap address and heap size for pid |
| MMAP_PROC_STACKINFO | Stack address and stack size for pid |
| FS_AIONR | Running total of the number of events specified on the io_setup system call for all currently active aio contexts |
| FS_AIOMAXNR | MAX AIONR possible. If aio-nr reaches aio-max-nr then io_setup will fail with EAGAIN |
| FS_FILENR | Number of allocated file handles, the number of allocated but unused file handles, and the maximum number of file handles |
| FS_FILEMAXNR | Maximum number of file-handles that the Linux kernel will allocate. |
| CPU_CORECOUNT | Core count |
| CPU_THREADCOUNT | Total thread count (CPU count) |
| PROCSET_NUMCPU | Get current number of CPUs in caller’s processor set |
| CPU_ARCHINFOALL | Struct which has socket,core and thread count |
| MEM_HUGEPAGESIZE | Size of a huge page |
| MEM_HUGEPAGEALL | Struct with all information about huge pages |
| VMSTAT_PAGEIN | Number of page in since last boot |
| VMSTAT_PAGEOUT | Number of page out since last boot |
| VMSTAT_SWAPIN | Number of swapin since last boot |
| VMSTAT_SWAPOUT | Number of swapout since last boot |
| VMSTAT_PGMAJFAULT | Number of major page faults per sec. |
| VMSTAT_INFOALL | All information related to VMSTAT. |
| LOADAVG_INFO | All information related to load average; CPU and IO utilization of the last one, five, and 10 minute periods. It also shows the number of currently running processes and the total number of processes. |
-
We need to start thinking about how we can virtualize the information provided by the library. Currently all the information which is provided is not virtualized because they are fetched from /proc which itself is not virtualized. This means if an application is running in a containerized environment then the information provided by the library may not necessarily be for the container itself, it might be information of the host system.
One suggestion was to read this information using LXCfs which is a file system that can be bind mounted over /proc to provide cgroup aware information. But this seems to be pretty heavy because it uses FUSE to get cgroup aware container information.
Another suggestion was to read this information for cgroup files and provide them to application. This seems more efficient and an ideal solution for the problem.
-
libresource internally reads the information from procfs or sysfs itself, so currently it does not provide any performance improvement over reading that information directly from procfs or sysfs. We need to figure out ways to get the information in a more efficient manner.
Various efforts have been made to add a system call or similar interface to provide this information, but none have been accepted by the community so far.
-
There was a suggestion to use netlink to get some of the kernel information, especially networking related information. I had tried that while working on networking resources in first version of the library, but I did not see any performance improvement in comparison to getting the information from procfs. This is because we still need to open a socket and read information from it, parse the information and close the socket.
If in the future we provide APIs to read system resource information continuously, then this might be useful. We can keep the socket open and read the information continuously.
-
There was a suggestion to standardize the make/install processes. Currently the library has a simple Makefile which does the work. We are working on this in next version.
I am working on a lot of these suggestions for the next version of libresource and they should be out for review and later for use soon. Meanwhile you can get the library from github[3] and start using it. If you have a request or a question, please use the issues[4] page on the github repository.
[1] https://blogs.oracle.com/linux/getting-system-resource-information-with-a-standard-api
[2] https://www.linuxplumbersconf.org/event/2/contributions/211/
[3] https://github.com/lxc/libresource
[4] https://github.com/lxc/libresource/issues