Eliminating the Monitor Daemon: New PSI and Poll Backends for Glib's GMemoryMonitor API

The GMemoryMonitor [1] API always works with a memory monitoring backend that periodically monitors the memory usage and then signals the GMemoryMonitor API about the low memory status. The monitor daemon monitors the system memory usage and listens to the Linux Kernel memory pressure stall information (PSI) [2], then reports the event to the GMemoryMonitor API via DBus signal. The daemon signals the application and then the application starts to reduce its memory usage demand. However, the reliance on a daemon means GMemoryMonitor may not be able to work if the daemon fails or if the application is running in a container. These backends daemons support the API and Linux system, including RHEL and Fedora, to run.To simplify the data flow and reduce the number of active daemons in RHEL and Fedora, integrating into Glib was a good option. The last question was how Glib monitors the memory usage.

This work integrated the monitoring algorithm into Glib itself to monitor the local memory usage and memory PSI events. Two backends are introduced to the GMemoryMonitor API. According to systemd [3], the Linux kernel PSI event backend is a Linux-specific backend and it watches the Linux kernel memory PSI event and reports the event to the applications. The polling backend polls the memory usage periodically and estimates the free memory ratio. If the free memory ratio drops to a certain threshold, it signals the applications. The original DBus backend was kept for compatibility. The GMemoryMonitor API now runs independently without a daemon to feed data and is 100% compatible with the original API usage.

The Linux kernel PSI monitors and estimates the resource usage in a given time period. It generates an event for the listener when it detects usage problems, such as task stall time. The basic concept is that if a task is blocked by a resource for a period of time, the kernel signals the listener. The kernel takes on all the monitoring and event reporting tasks, which is beneficial. GMemoryMonitor sets up the PSI monitoring parameters and waits for the memory events. The poll backend is a fallback implementation when GMemoryMonitor can’t find any supported backends. It periodically polls the system memory usage and estimates the free memory ratio. If the ratio is lower than a certain threshold, it signals the caller.

By integrating the memory monitoring algorithm directly into Glib, this work successfully introduced the Linux PSI and Poll backends for the GMemoryMonitor API. This fundamental shift eliminates the dependency on an external monitor daemon, allowing GMemoryMonitor to operate independently and making it more reliable, particularly in containerized environments. Crucially, the new approach remains 100% compatible with the original API usage, while simplifying the system’s architecture and streamlining the data flow for memory pressure signals.

[1] https://docs.gtk.org/gio/iface.MemoryMonitor.html
[2] https://docs.kernel.org/accounting/psi.html
[3] https://systemd.io/MEMORY_PRESSURE/

Work with AI tools using granite.code

The used of AI tool to speed up the coding efficiency becomes a new trend in the programming field and industry. The upstream contributors and maintainers are trying to use those tool to improve the development speed and reduce the workload. Those new technologies also catch my eyes and I’ll give them a try. Many AI code assistance tools were proposed and they were based on the open AI model, for example Github copilot. But If you concern about the security and you don’t allow the information leak.

Here I’ll ask the local model Granite.code to tell us how to install and deply it locally. It gave me the answer shown bellow.

1
2
3
4
5
6
7
8
9
10
11
12
13
As an AI developed by IBM, I don't have the capability to directly guide you through deploying Granite.Code
on your local machine as it's not publicly available for such use. However, I can provide a general outline
of steps you might follow if Granite.Code were available for local deployment:

Check System Requirements: Ensure your laptop meets the necessary system requirements to run Granite.Code.
This typically includes specifications like operating system version, RAM, and CPU capabilities.

Download the Software: If Granite.Code were publicly available, you would download it from an official source.
As of now, there's no public release for local deployment.

Installation: Extract or run the installer, following the instructions provided in the documentation. This
usually involves agreeing to terms and conditions, choosing installation directory, etc.
...

Hmm, It try to invite the user to use the Could version. Here is the steps to deploy Granite.code to your local laptop. Moreover, first, you have to ensure you have a Mac M2 or have a GPU support. Then, checkout the IBM website to get the detailed step to deploy it and the URLs are shown as follows.

My configuration is a bit tricky since my working laptop doesn’t have a GPU or something can accelerate the AI compute. So, I ran the model on my Mac M2 (Yes, a Mac, haha) and tweaked the Watson code assistant to access the API server on my M2.

OK, now, I ask granite.code for a Glib hello world example and here is the answer. That gave a pieces of example and the expected out comes.
Hello world

Watson code assistant provide four main functions, Describe the code, unit test generator, document generator, and code completion. However, M2 is slow so I have to skip the code completion. I really love to use code describe, it give me a glance if I first trace the code.
Here is the example:

1
/explain up_daemon_get_on_ac_local

I got:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
This C code is a function named 
up_daemon_get_on_ac_local
. Here's a breakdown of what it does:

Function Signature:

The function takes two parameters: a pointer to an 
UpDaemon
 structure (
daemon
) and a boolean pointer (
has_ac
).
It returns a boolean value (
gboolean
).
Local Variables:
...
<skip> 
...
In summary, this function checks each device associated with a daemon to see if there's at least one that is both online and has AC power. If such a device exists, it sets 
result
Copy to TRUE; otherwise, it remains FALSE. It also optionally updates the 
has_ac
 parameter if set.

It gave me a summary of input parameters, local vaiables, and a summary of the function. It took 1min to analyze the code
and generate the result. It is useful before you deep dive into the code.

The document generator generate the doxygen comment format. It it a bit different from GTK comment but I can translate
it to the GTK format. That is good for me. The example was shown as follows. It looks normal but it still needs some
work to make it to a API document.

1
2
3
4
5
6
7
8
9
10
11
/**
 * @brief Retrieves whether the system is on AC power locally.
 * 
 * This function checks each device in the list of power devices to determine if any are currently connected to AC power.
 * If the 'has_ac' parameter is not NULL, it will be set to TRUE if at least one device is connected to AC power.
 * The main return value (result) indicates whether any device was found to be on AC power.
 * 
 * @param daemon A pointer to an UpDaemon structure containing the list of power devices.
 * @param has_ac A pointer to a boolean variable that will be set to TRUE if at least one device is connected to AC power, if not NULL.
 * @return gboolean - Returns TRUE if any device was found on AC power, FALSE otherwise.
 */

For the unit test code generator, it only gave the gtest code. However, for our Glib developers, we can’t use this feature.

Coding with a local AI assistance is a very good idea. It is like a virtual colleague to answer your question. However, it
needs a powerful computer to make it come true. My Mac M2 took a few minutes to analyze question and generate the result.
Base on this performance, The code completion can’t be a really powerful tool for me. The feature mentioned above is
nice and worst to wait for the result. It inspired me to make higher quality documents and it also listed all the possible
stuff. To have a AI tools for coding actually improves the code quality and development efficiency.

upower: Support Multiple Keyboard Backlight LED Control

Upower can only set one keyboard backlight LED brightness. It finds the first keyboard backlight LED sysfs entry and then set up the DBus API entry for it. This works on most of the laptops but can’t work on some gaming laptops which have more than one keyboard backlight LED needs to take care. Moreover, if a USB keyboard with backlight LED was attached to laptop, upower has to discover it and set up or remove the API entry dynamically. The previous MR [1] proposed an implementation to setup multiple brightness but it can’t add/remove the device information automatically.
The new proposed MR [2] was based on udev event which gave as the device status when user install or remove a keyboard backlight LED device. Through this way, the DBus API entry and device information can be added/removed with the the udev events like what we do for the batteries. In the mean time, a abstraction class for keyboard backlight LED was proposed so upower can support different implementation, such as Linux, FreeBSD, and more [3].

[1] https://gitlab.freedesktop.org/upower/upower/-/merge_requests/203
[2] https://gitlab.freedesktop.org/upower/upower/-/merge_requests/258
[3] https://gitlab.freedesktop.org/upower/upower/-/issues/291

The policy for connecting a low power charger in Upower

Upower determines the battery charging status according to the battery charging status now. Upower sets the on_battery status to no when connecting any kind of chargers. In other words, upower ignores the battery charging status (charging/discharging) when any charger connects to a device. The original policy is good for the most of laptops with a traditional AC power adaptor. Today, we can charge the battery through a PD charger (a type-C charger) which provides different capability of charging. Yet, this cause the problems for the devices. For example, we play the cellphone game with a 5w charger and the battery discharges to maintain the performance. In this case, upower thinks that a AC charger is online so upower can ignore the battery status. Therefore, battery continue to discharge until running out of battery. The vital gaming data may lost.

Alpine Linux folks found this issue and we tried to resolve it. Now, Upower was able to show the real status for the battery when a low power charger connect to the device. Upower determines the battery status based on the current value. Upower will set on_battery status to yes, if it finds the battery discharges (a negative current value) in any conditions. This work is waiting for Alpine Linux to test it. Once it get landed, this fix will be included in the next release of upower.

[1] https://gitlab.freedesktop.org/upower/upower/-/merge_requests/244

Logitech G510 keyboard backlight supports multicolor LED API

We made the Logitech G510 keyboard to support standard multi-color LED API to configure the keyboard backlight LED colors and brightness. The legacy sysfs property “color” was removed. We invite the user or apps that configure LED color through that property to use the new one.

The G510 owner can change the color of the keyboard backlight LED through the following command

1
2
# make LED show red.
echo "255 0 0" > /sys/class/led/g15::kbd_backlight/intensity

and change the brightness through

1
echo "100" > /sys/class/led/g15::kbd_backlight/brightness

Thank you for Hans’ review.

[1] https://lore.kernel.org/linux-input/20250131140241.586305-1-hpa@redhat.com/T/#u