Summary: | x11-misc/parcellite-1.0.2_rc5 generates too many interrupts (as seen in powertop) | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Bernardo Costa <bernardofpc> |
Component: | Current packages | Assignee: | Desktop Misc. Team <desktop-misc> |
Status: | RESOLVED OBSOLETE | ||
Severity: | normal | ||
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
Bernardo Costa
2012-09-27 23:19:50 UTC
Could something be abusing the cut buffer / clipboard on your system? I don't see this running under x11-wm/musca. 1.1% ( 4.0) parcellite By comparison, www-client/opera-next triggers 10 times a second, and net-im/psi 15 times a second. (In reply to comment #1) > Could something be abusing the cut buffer / clipboard on your system? I > don't see this running under x11-wm/musca. I have no idea what could generate that, but I'll give a try to a different wm. Do you know any way to get the call trace that generates all those interrupts (for instance if I compile with -g and tell something smart to the kernel?) > 1.1% ( 4.0) parcellite > > By comparison, www-client/opera-next triggers 10 times a second, and > net-im/psi 15 times a second. Are you using powertop 1.x? This looks like it. Powertop 2.1 has a different table format, so mine now looks lik: Power est. Usage Events/s Category Description 2.41 W 64.7 ms/s 238.9 Process firefox 392 mW 2.4 ms/s 59.0 Process parcellite But in any case you're getting far less interrupts (correct me if I'm wrong, the old powertop had (Total events) and a 10s sampling time). (In reply to comment #1) > Could something be abusing the cut buffer / clipboard on your system? I > don't see this running under x11-wm/musca. I have just tried musca on X:1, and I get essentially the same numbers as for blackbox. I have even tried just a plain startx /usr/bin/xterm and I still get the bad figures. I have not closed my blackbox session, but I assumed that on a different X server it would never interfere. (In reply to comment #3) > (In reply to comment #1) > > Could something be abusing the cut buffer / clipboard on your system? I > > don't see this running under x11-wm/musca. > I have just tried musca on X:1, and I get essentially the same numbers as > for blackbox. I have even tried just a plain startx /usr/bin/xterm and I > still get the bad figures. I have not closed my blackbox session, but I > assumed that on a different X server it would never interfere. I have made a fresh start for X, and upon startx /usr/bin/xterm then launching parcellite I still measure 50-70 events/s on powertop. Even worse, just watching top I see parcellite's run time increase steadly (admittedly at a slow pace of .02s per update, but that's still 1% cpu time). Any debugging suggestions? Or perhaps looking into USE flags / kernel config? What if you stopped firefox for a bit? (In reply to comment #5) > What if you stopped firefox for a bit? That was the "fresh X start". I had only xterm (for running powertop) and parcellite running. I could try just # startx "parcellite -n" & and follow powertop on VT2, but I only thought about it on reading your message (and it's a bit silly if *any* X program makes parcellite go crazy on interruptions, it's more a sign to change the clipboard manager). And yes, firefox was high because of GMail with chat enabled. (In reply to comment #2) > (In reply to comment #1) > > Could something be abusing the cut buffer / clipboard on your system? I > > don't see this running under x11-wm/musca. > > > > 1.1% ( 4.0) parcellite > > > > By comparison, www-client/opera-next triggers 10 times a second, and > > net-im/psi 15 times a second. > Are you using powertop 1.x? This looks like it. Powertop 2.1 has a different > table format, so mine now looks lik: > > > Power est. Usage Events/s Category Description > 2.41 W 64.7 ms/s 238.9 Process firefox > 392 mW 2.4 ms/s 59.0 Process parcellite > > But in any case you're getting far less interrupts (correct me if I'm wrong, > the old powertop had (Total events) and a 10s sampling time). Weeeeeeeeeeell. I was running out of ideas, then I decided to give powertop-1.3 a try. So here are my top offenders: Top causes for wakeups: 42.3% ( 72.1) firefox 26.8% ( 45.7) [Rescheduling interrupts] <kernel IPI> 22.7% ( 38.7) [iwlwifi] <interrupt> 2.3% ( 4.0) parcellite 1.2% ( 2.0) swapper/4 This is for a 5s interval. So this is probably the fact that powertop-2.1 is completely different from powertop-1.3. Perhaps it reports more wake-ups because it's more accurate in looking at kernel information, perhaps it's just noisier. I'll do some checking to see if I can confirm this hypothesis, but I feel that this bug will probably be invalid after all... Anyway, tt's very bad for powertop to have such enormous differences and don't have a nice page explaining why that changed. I feel that all doc is either relative to the old one (on http://www.lesswatts.org/projects/powertop/) or the new one (on 01.org) but it almost seems as both are unrelated other than the name. Continuing my powertop experiences, I discovered that probably version 2.x do a lot more of statistics gathering than the previous version. It seems to me that after all parcellite is making that much events, as I can see in strace'ing it. Most look like poll/read/write/recvfrom/writev in the X11 communication protocol, and triggered by a single timer. So if I make the bold assumption that powertop-1.13 was tracing just wakeups (from otherwise idle systems), whereas powertop-2.1 traces some syscalls as "events", then this would make the figures match. In any case, I sense a problem in the way that X11-Selections work, because there's no possible way to notify a program that a new selection arrived, unless this program owns the window that owns the Selection. Of course, you can make parcellite reown the selection each time, but this has some bad consequences I can see: - this would un-highlight the text the instant after parcellite takes ownership - by doing it, some smart click-copy becomes impossible, because nowadays one cannot even try to be faster that all these notifications (put aside X11-timestamp synchronization). The best example is "letter-word-line" in terminals, triggered by double-triple-quadruple clicks. Perhaps there's no way out of it. New data is required from current stable, 1.1.7 |