GNOME Bugzilla – Bug 353670
gtkentry cursor blinking causes gdmgreeter to have many needless context switches
Last modified: 2006-08-31 15:39:43 UTC
We're working (with RH kernel engineers) to make the kernel have a "tickless idle", with the goal to make an idle system have as little to do as possible. This effort more or less depends on userspace also not having too many frequent events, so that the "really idle" times get as long as possible for maximum power savings. As part of this effort, the gdmgreeter showed up as a major cause of context switches per second. Since many servers will normally be at the gdmgreeter screen (chugging along on background workload waiting for an admin to log in which may almost never happen), we investigated this more. The root-cause turns out to be cursor blinking, specifically the code in gtkentry. The existing code is suboptimal in several ways, and the patch that I will attach fixes several of these. 1. Needless use of floating point. When an application uses floating point, the kernel is required to first restore the floating point context (this happens on demand on first use of a floating point operation after a context switch) and then later save the full floating point context when the app context-switches away. While not extremely expensive, it's not a cheap operation either. The cursor blinking code used floating point to calculate a hard-coded 1/3rd and 2/3rd, and since this code was also causing many context switches, this cost was silly and unneeded. 2. Empty entry boxes blinked forever While a blinking cursor is useful to find it in the middle of text, when the entire entry box is empty, it's far less useful. I understand that this is a controversial and UI visible change, so I made it an option for applications to set a flag that empty entry boxes shouldn't blink. Attached is also a patch to gdm to make use of this flag. On a fully idle FC6test system, the gdmgreeter blinking cursor caused 6 to 8 context switches per second (idle switches to gdmgreeter switches to X and back, X does syscalls to the kernel for the DRM accelerated cursor drawing, and that both for turning on and turning off the painting of the cursor) With the attached patches applied, these context switches no longer happen and an idle gdmgreeter no longer impacts system performance or system power use. 3. Emtpy entry boxes blinked at the same speed For those entry boxes that don't have the 'dont blink on empty' flag set, empty boxes can still reduce system load/power usage some by blinking at a lower speed. The attached patch halves the blinking rate if the entry box is idle. 4. gtk_entry_check_cursor_blink() had a race the gtk_entry_check_cursor_blink() code first set the timer, and THEN showed the cursor. If the app happens to get scheduled away, the timer may have fired before the cursor is shown, which is incorrect. Fix is simple, do it in the other order and mimic the blink_cb() function which already did this correctly.
Created attachment 71953 [details] [review] Patch to the gtkentry code to resolve the issues in this bug
Created attachment 71954 [details] [review] Patch to gdm(greeter) to use the new infrastructure from the previous patch
Created attachment 71967 [details] [review] Updated patch based on feedback; obsoletes all previous patches New patch inspired by http://www.manucornet.net/pub/olpc/enhancements/cursor_blink_lifetime.diff from Manu Cornet <manu@manucornet.net> Instead of having a property etc, just stop blinking after a configurable amount of time of inactivity (default: 60 seconds) Other bugfixes are still the same
So, does your patch obsolete Manu's? Dupping. Please followup in the other bug. *** This bug has been marked as a duplicate of 352442 ***