GNOME: Pika Backup Hopping Through Milestones and Improving poll() Timeout Precision

posted by Roy Schestowitz on Mar 04, 2024

• GNOME ☛ Sophie Herold: Pika Backup Hopping Through Milestones

  Pika Backup is an app focused on backups of personal data. It’s internally based on BorgBackup and provides fast incremental backups.

  Last year, Pika Backup crossed the mark of 100,000 downloads on Flatub. These are numbers I couldn’t have imagined when submitting Pika Backup to Flathub only about three years ago. Thanks to everyone who has supported the project along the way. Be it with incredibly kind feedback, helpful issue reports, or financial contributions on Open Collective. It has been a blast so far. A special thanks goes to BorgBase who generously has been giving financial support to the project development for over a year now.

• GNOME ☛ Christian Hergert: Improving poll() timeout precision

  Recently I was looking at a VTE performance issue so I added a bunch of Sysprof timing marks to be picked up by the profiler. I combined that with GTK frame timing information and GNOME Shell timing information because Sysprof will just do that for you. I noticed a curious thing in that almost every ClutterFrameClock.dispatch() callback was rougly 1 millisecond late.

  A quick look at the source code shows that ClutterFrameClock uses g_source_set_ready_time() to specify it’s next deadline to awaken. That is in µsec using the synchronized monotonic clock (CLOCK_MONOTONIC).

  Except, for various reasons, GLib still uses poll() internally which only provides 1 millisecond timeout resolution. So whatever µsec deadline was requested by the ClutterFrameClock doesn’t really matter if nothing else wakes up around the same time. And since the GLib GSource code will always round up (to avoid spinning the CPU) that means a decent amount late.

  With the use of ppoll() out of question, the next thing to use on GNU/Linux would be a timerfd(2).