Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 436448 - x11-misc/parcellite-1.0.2_rc5 generates too many interrupts (as seen in powertop)
Summary: x11-misc/parcellite-1.0.2_rc5 generates too many interrupts (as seen in power...
Status: RESOLVED OBSOLETE
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: Desktop Misc. Team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-09-27 23:19 UTC by Bernardo Costa
Modified: 2014-04-23 15:29 UTC (History)
0 users

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Bernardo Costa 2012-09-27 23:19:50 UTC
I use parcellite with blackbox, and upon monitoring with powertop (version 2.1) I discovered it generates some 40 - 70 Events/s, which sounds like too much.

Stracing parcellite indicates a lot of polling events on 2 fds which are a socket and an "anon inode". Also the process itself has had some 2h cumulative uptime, whereas it was lounched less than 20h ago.

I have another computer with kubuntu, but the same situation (blackbox w/ parcellite) triggers much less events/s (10-ish), but that still seems excessive, I have seen "bug reports" about 6 events/s for parcellite finding it's too much, and I agree, such an application should not have to check every epsilon interval to see if something has changed on the clipboard. (my guess, but it could be that the polling is done for a completely different thing, but that would surprise me even more).
Comment 1 Jeroen Roovers (RETIRED) gentoo-dev 2012-09-28 15:07:28 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.
Comment 2 Bernardo Costa 2012-09-28 22:32:08 UTC
(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).
Comment 3 Bernardo Costa 2012-09-28 23:04:35 UTC
(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.
Comment 4 Bernardo Costa 2012-09-29 05:09:36 UTC
(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?
Comment 5 Jeroen Roovers (RETIRED) gentoo-dev 2012-09-29 15:56:32 UTC
What if you stopped firefox for a bit?
Comment 6 Bernardo Costa 2012-09-29 16:13:08 UTC
(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.
Comment 7 Bernardo Costa 2012-09-30 03:35:34 UTC
(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.
Comment 8 Bernardo Costa 2012-10-08 19:44:07 UTC
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.
Comment 9 Samuli Suominen gentoo-dev 2014-04-23 15:29:47 UTC
New data is required from current stable, 1.1.7