X

News, tips, partners, and perspectives for the Oracle Linux operating system and upstream Linux kernel work

libresource - It is time for version 2

Scott Michael
Director, Software Development

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

Be the first to comment

Comments ( 0 )
Please enter your name.Please provide a valid email address.Please enter a comment.CAPTCHA challenge response provided was incorrect. Please try again.