More than 2300 wakeup cycles per second [LWN.net]

More than 2300 wakeup cycles per second

Posted Apr 6, 2012 8:04 UTC (Fri) by cladisch (✭ supporter ✭, #50193)
In reply to: More than 2300 wakeup cycles per second by jzbiciak
Parent article: OSADL on realtime Linux determinism

I do have /proc/timer_stats

So your kernel has the statistics gathering code.

but it provides nothing interesting

RTFM

(Log in to post comments)

More than 2300 wakeup cycles per second

Posted Apr 6, 2012 15:24 UTC (Fri) by jzbiciak (✭ supporter ✭, #5246) [Link]

Well, all right then. Just before I started typing this reply, I echo'd a 1 into /proc/timer_stats to see what it might turn up. And what do we have here, 2 minutes later?

Oy... plenty! Actually, the interrupt profile seems pretty diffuse. One standout is the gazillion evince processes I have running. I have a horrible habit of opening data sheets / documentation PDFs, and then leaving them open. strace -p <pid of random evince> ... Holy cats! That's a busy-looking poll loop that does.... nothing useful? The inotify file descriptor apparently has plenty to tell evince (about 3.3K worth each poll()), but why? Hmmm.

Curiouser and curiouser. Now I'm off to go down this rabbit hole...

More than 2300 wakeup cycles per second

Posted Apr 6, 2012 15:54 UTC (Fri) by jzbiciak (✭ supporter ✭, #5246) [Link]

Aha... Many of these PDFs live in /tmp. Evince watches the directory holding the PDF so that it can (for better or for worse) auto-refresh if the file its displaying gets replaced with an updated version. Instead, it just gets a bunch of update events for all of the "vteXXXX" files that are actually deleted(!) but still open for all of my umpteen gnome-terminal windows.

Wow, is THAT a worthless use of resources!

More than 2300 wakeup cycles per second

Posted Apr 6, 2012 16:33 UTC (Fri) by jzbiciak (✭ supporter ✭, #5246) [Link]

Hmmm... I can't even decide whose fault it is for all this. It looks like a little from column "A", a little from column "B" and a little from column "C":

There doesn't seem to be a way to tell evince not to watch the directory containing the PDF file it's viewing.
There doesn't seem to be a way to make gnome-terminal not update a file in /tmp every time it gets a line of display output. (But boy, is there a discussion on it! At least they're going to move to a different directory, it appears.)
The kernel is sending file-change notifications to evince based on it watching /tmp, but the files that changed are unlinked, and their fds aren't open by evince. "Something you can't see and can never see changed." Whaa?

At least I can come out of the rabbit hole, even if I don't have a ready solution. :-P

More than 2300 wakeup cycles per second

Posted Apr 7, 2012 18:15 UTC (Sat) by madscientist (subscriber, #16861) [Link]

Ready solution (to at least part): xterm! I never use gnome-terminal myself: too much overhead.

More than 2300 wakeup cycles per second

Posted Apr 10, 2012 20:47 UTC (Tue) by zooko (subscriber, #2589) [Link]

Does anybody have links to issue tickets for these three issues? I'd like to keep track, see if I can upgrade or switch tools or maybe even do a patch review or something.