|
Bugzilla – Full Text Bug Listing |
| Summary: | hald/battstat applet chewing CPU ... | ||
|---|---|---|---|
| Product: | [openSUSE] SUSE LINUX 10.0 | Reporter: | Michael Meeks <mmeeks> |
| Component: | GNOME | Assignee: | E-mail List <gnome-bugs> |
| Status: | RESOLVED WONTFIX | QA Contact: | E-mail List <qa-bugs> |
| Severity: | Normal | ||
| Priority: | P5 - None | ||
| Version: | Final | ||
| Target Milestone: | --- | ||
| Hardware: | Other | ||
| OS: | Other | ||
| Whiteboard: | |||
| Found By: | Other | Services Priority: | |
| Business Priority: | Blocker: | --- | |
| Marketing QA Status: | --- | IT Deployment: | --- |
ACPI can be unreliable with events so hal resorts to polling it. The current battstat applet does not use hal, but we'll be replacing it with one that does for nld 10 (like gnome-power manager or something like it). |
It seems the battstat applet likes to poll /proc/apm (in APM mode) rather regularly: once per second I get: 1129538207.808299 poll([{fd=17, events=POLLIN}, {fd=3, events=POLLIN}, {fd=26, events=POLLIN|POLLPRI}, {fd=28, events=POLLIN|POLLPRI}, {fd=29, events=POLLIN|POLLPRI}, {fd=30, events=POLLIN|POLLPRI}, {fd=33, events=POLLIN|POLLPRI}, {fd=31, events=POLLIN|POLLPRI}, {fd=34, events=POLLIN|POLLPRI}, {fd=35, events=POLLIN|POLLPRI}], 10, 717) = 0 1129538208.533235 gettimeofday({1129538208, 535807}, NULL) = 0 1129538208.535994 open("/proc/apm", O_RDONLY) = 36 1129538208.536172 fstat64(36, {st_mode=S_IFREG|0444, st_size=0, ...}) = 0 1129538208.536276 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40029000 1129538208.536321 read(36, "1.16ac 1.2 0x03 0x01 0x00 0x01 1"..., 1024) = 41 1129538208.553297 close(36) = 0 1129538208.553462 munmap(0x40029000, 4096) = 0 1129538208.553521 ioctl(3, FIONREAD, [0]) = 0 1129538208.553562 gettimeofday({1129538208, 553569}, NULL) = 0 It often comes onto my 'top' - chewing a percentage of CPU. It's really not clear to me that this polling is necessary; in an ideal world surely we'd get a kernel generated HAL event ? but - worse - hald is also doing a chunk of work here: 1129538316.102195 gettimeofday({1129538316, 102278}, NULL) = 0 1129538316.104001 open("//proc/apm", O_RDONLY|O_LARGEFILE) = 3 1129538316.111954 fstat64(3, {st_mode=S_IFREG|0444, st_size=0, ...}) = 0 1129538316.120840 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7f47000 1129538316.123954 read(3, "1.16ac 1.2 0x03 0x01 0x00 0x01 1"..., 1024) = 41 1129538316.136679 close(3) = 0 1129538316.142844 munmap(0xb7f47000, 4096) = 0 1129538316.143961 open("//proc/apm", O_RDONLY|O_LARGEFILE) = 3 1129538316.151995 fstat64(3, {st_mode=S_IFREG|0444, st_size=0, ...}) = 0 1129538316.159956 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7f47000 1129538316.167379 read(3, "1.16ac 1.2 0x03 0x01 0x00 0x01 1"..., 1024) = 41 1129538316.171957 close(3) = 0 1129538316.179958 munmap(0xb7f47000, 4096) = 0 1129538316.188001 gettimeofday({1129538316, 188484}, NULL) = 0 1129538316.194678 poll([{fd=5, events=POLLIN}, {fd=10, events=POLLIN}, {fd=7, events=POLLIN}, {fd=9, events=POLLIN|POLLPRI}, {fd=8, events=POLLIN}, {fd=12, events=POLLIN}], 6, 1914) = 0 Of course - hald appears to like to read /proc/apm -twice- every two seconds ~thus presumably giving higher latency without reduced cost ;-> - all looks a little bit odd to me ...