User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.0.3) Gecko/2008092816 Iceweasel/3.0.3 (Debian-3.0.3-1) Build Identifier: pool/main/x/xfce4-clipman-plugin/xfce4-clipman-plugin_0.8.1-1_i386.deb When running xfce4-clipman-plugin on my system, it is responsible for almost 50% of my wackups-from-idle. Why does xfce4-clipman-plugin use so much resources when the system is in idle? What are the options to fix this? I would really appreciate a fix for this issue. See the attached screenshot for the powertop statistics. Reproducible: Always Steps to Reproduce: 1. 2. 3.
Created attachment 1872 screenshot powertop statistics
50% ok, but only 4 wps, which is not that much, eh? I find this a non-bug.
(In reply to comment #2) > 50% ok, but only 4 wps, which is not that much, eh? I find this a non-bug. Would you be willing to explain to me why the panel and xorg use 1 wps and xfce-clipman-plugin 4wps this is an almost 400% higher interrupt rate, I just don't understand why this is necessary. I am doing some research on some embedded xfce system and all bits help.
You should be glad you have this score already, you know? There's no point taking ages reducing wps at that stage. If you find an obvious bug, sure, go ahead, provide a patch. I'm not sure the dev really have time for this kind of game (I'm not the dev, though). Cheers, -- Yves-Alexis
Created attachment 1873 screenshot powertop statistics with firefox as comparison
(In reply to comment #4) > You should be glad you have this score already, you know? There's no point > taking ages reducing wps at that stage. If you find an obvious bug, sure, go > ahead, provide a patch. I'm not sure the dev really have time for this kind of > game (I'm not the dev, though). I understand this does not seem as a big issue, but I am analyzing the idle situations and even if you compare the xfce-clipman-plugin to a big applications like firefox(iceweasel) you can see the clipman-plugin generates far more interrupts. This just does not look heathy. I would really appreciated it if somebody checks out the clipman-plugin source code to search for some oversizes timer and interrupt settings that can cause this behavior. Thank in advance,
The scores just look spurious to me: corsac@miria: sudo powertop -d PowerTOP 1.10 (C) 2007, 2008 Intel Corporation Collecting data for 15 seconds < Detailed C-state information is not available.> P-states (frequencies) Wakeups-from-idle per second : 575,4 interval: 15,0s no ACPI power usage estimate available Top causes for wakeups: 57,1% (251,1) epiphany-browse : futex_wait (hrtimer_wakeup) 23,8% (104,6) npviewer.bin : schedule_timeout (process_timeout) 7,5% ( 33,1) liferea-bin : schedule_timeout (process_timeout) 3,6% ( 15,7) <interrupt> : ata_piix, ata_piix 2,3% ( 10,0) gnome-do : futex_wait (hrtimer_wakeup) 0,9% ( 4,1) <kernel module> : usb_hcd_poll_rh_status (rh_timer_func) 0,7% ( 3,2) xfce4-terminal : schedule_timeout (process_timeout) 0,7% ( 2,9) xfce4-clipman-p : schedule_timeout (process_timeout) 0,6% ( 2,8) <interrupt> : eth0 0,5% ( 2,0) <kernel core> : clocksource_register (clocksource_watchdog) 0,5% ( 2,0) liferea-bin : futex_wait (hrtimer_wakeup) 0,2% ( 1,0) xfce4-panel : schedule_timeout (process_timeout) 0,2% ( 1,0) xfce4-mixer-plu : schedule_timeout (process_timeout) 0,2% ( 1,0) ifconfig : tg3_open (tg3_timer) 0,1% ( 0,5) <kernel core> : cpucache_init (delayed_work_timer_fn) 0,1% ( 0,5) slim : do_setitimer (it_real_fn) 0,1% ( 0,5) hald-addon-stor : schedule_timeout (process_timeout) 0,1% ( 0,4) xfce4-places-pl : schedule_timeout (process_timeout) 0,1% ( 0,3) <kernel core> : neigh_table_init_no_netlink (neigh_periodic_timer) 0,1% ( 0,3) <kernel module> : neigh_table_init_no_netlink (neigh_periodic_timer) 0,1% ( 0,3) apt-get : neigh_add_timer (neigh_timer_handler) 0,0% ( 0,2) init : schedule_timeout (process_timeout) 0,0% ( 0,2) Xorg : __netdev_watchdog_up (dev_watchdog) 0,0% ( 0,2) Thunar : schedule_timeout (process_timeout) 0,0% ( 0,2) gnome-do : schedule_timeout (process_timeout) 0,0% ( 0,2) <kernel core> : page_writeback_init (wb_timer_fn) 0,0% ( 0,1) xfdesktop : schedule_timeout (process_timeout) 0,0% ( 0,1) xfdesktop : hrtick_set (hrtick) 0,0% ( 0,1) xfce4-menu-plug : schedule_timeout (process_timeout) 0,0% ( 0,1) xfce4-menu-plug : hrtick_set (hrtick) 0,0% ( 0,1) cli : do_nanosleep (hrtimer_wakeup) 0,0% ( 0,1) <interrupt> : uhci_hcd:usb1, HDA Intel, i915@pci:0000:00:02.0 0,0% ( 0,1) Xorg : hrtick_set (hrtick) 0,0% ( 0,1) <kernel core> : input_handle_event (input_repeat_key) 0,0% ( 0,1) Xorg : schedule_timeout (process_timeout) 0,0% ( 0,1) <kernel core> : ip_rt_init (delayed_work_timer_fn) 0,0% ( 0,1) sh : start_this_handle (commit_timeout) 0,0% ( 0,1) slim : start_this_handle (commit_timeout) 0,0% ( 0,1) ssh-agent : schedule_timeout (process_timeout) 0,0% ( 0,1) gconfd-2 : schedule_timeout (process_timeout) 0,0% ( 0,1) cron : do_nanosleep (hrtimer_wakeup) 0,0% ( 0,1) USB device 1-1.1 : CS-1732A V3.4.331 (ATEN) A USB device is active 100,0% of the time: /sys/bus/usb/devices/1-1 Suggestion: Enable USB autosuspend by pressing the U key or adding usbcore.autosuspend=1 to the kernel command line in the grub config Suggestion: increase the VM dirty writeback time from 5,00 to 15 seconds with: echo 1500 > /proc/sys/vm/dirty_writeback_centisecs This wakes the disk up less frequenty for background VM activity Suggestion: enable the noatime filesystem option by executing the following command: mount -o remount,noatime / or by pressing the T key noatime disables persistent access time of file accesses, which causes lots of disk IO. Suggestion: Disable 'hal' from polling your cdrom with: hal-disable-polling --device /dev/cdrom 'hal' is the component that auto-opens a window if you plug in a CD but disables SATA power saving from kicking in. Recent USB suspend statistics Active Device name 100,0% USB device 1-1.1 : CS-1732A V3.4.331 (ATEN) 100,0% /sys/bus/usb/devices/1-1 0,0% USB device usb7 : EHCI Host Controller (Linux 2.6.26-1-amd64 ehci_hcd) 0,0% USB device usb6 : UHCI Host Controller (Linux 2.6.26-1-amd64 uhci_hcd) 0,0% USB device usb5 : UHCI Host Controller (Linux 2.6.26-1-amd64 uhci_hcd) 0,0% USB device usb4 : EHCI Host Controller (Linux 2.6.26-1-amd64 ehci_hcd) 0,0% USB device usb3 : UHCI Host Controller (Linux 2.6.26-1-amd64 uhci_hcd) 0,0% USB device usb2 : UHCI Host Controller (Linux 2.6.26-1-amd64 uhci_hcd) 100,0% USB device usb1 : UHCI Host Controller (Linux 2.6.26-1-amd64 uhci_hcd) EOD.
FYI, the clipman plugin is most likely to be once again rewritten from scratch. I started to hack on trunk, and finally moved the work to a branch because integrating all the options starting to get the code nuts again. For now you have to either send patch against trunk, or wait-n-see what will happen next.
(In reply to comment #8) > FYI, the clipman plugin is most likely to be once again rewritten from scratch. Completely off-topic, but: good to hear! I'm having a lot of issues with clipman, but can't live without it either!
*** This bug has been marked as a duplicate of bug 4175 ***