| |||||||||||||
More than 2300 wakeup cycles per secondMore than 2300 wakeup cycles per secondPosted Apr 6, 2012 7:35 UTC (Fri) by jzbiciak (✭ supporter ✭, #5246)In reply to: More than 2300 wakeup cycles per second by cladisch Parent article: OSADL on realtime Linux determinism
I do have /proc/timer_stats, but it provides nothing interesting: $ cat /proc/timer_stats Timer Stats Version: v0.2 Sample period: 0.000 s 0 total events Ah well. And yes, you are correct that I'm not in the habit of compiling kernel updates. I suspect I'd have to move to a more tinker-friendly distro to make that a reality. I have to admit, I got out of the habit of compiling my own kernels just a bit before it got popular for distros to wrap a bunch of magic up in the kernel build process--initrd and all these related toys. I think the last "customized" kernel I compiled and booted was an early 2.6 series kernel, pre 2.6.9. The stock distro kernel has been "good enough" for almost a decade, if not more. Perhaps I'm just being a wuss or maybe I just don't care enough, but the last time I tried compiling a custom kernel on one of my machines, I eventually ran away screaming. That was only after a day or two of fighting with it that I finally gave up and went back to a vender kernel. (The last two times I believe I tried this were on RedHat 8 or 9 (pre-Fedora) and Ubuntu. Something tells me if I tried this, say, on Slackware or even Debian, I would be telling a different story.)
(Log in to post comments)
More than 2300 wakeup cycles per second Posted Apr 6, 2012 8:04 UTC (Fri) by cladisch (✭ supporter ✭, #50193) [Link] I do have /proc/timer_stats So your kernel has the statistics gathering code. but it provides nothing interesting
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":
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.
|
|||||||||||||