Taking a stand

Posted Nov 25, 2008 4:23 UTC (Tue) by tialaramex (subscriber, #21167)
Parent article: Observations on power management

Some of what needs to happen on issues like this is just a Debian-style stand on principle to eliminate problems even if this is briefly painful.

Beagle for example, survived early culls of awful software after Powertop by claiming that "soon" the Mono runtime would be fixed to eliminate its hopeless per-process (per-thread?) 10Hz timer that runs day & night, idle or busy. And once it had survived a few months this way, any feeling of urgency or even the vague idea that someone ought to /fix/ it went away, so here we are in November 2008, with people talking about the 2009 Linux distributions on the horizon, and not one of them seems to have "rip out Mono due to whale-murdering / wallet-emptying runtime" on its TODO list despite most of them talking about the importance of laptops & netbooks.

Taking a stand

Posted Nov 25, 2008 10:38 UTC (Tue) by pharm (guest, #22305) [Link]

Ubuntu moved to tracker for their indexing system IIRC

Taking a stand

Posted Nov 25, 2008 12:53 UTC (Tue) by Los__D (guest, #15263) [Link] (5 responses)

Ehm, my powertop seems to mark Tomboy (also uses the Mono runtime) as having around wakeups per second, and that is only when the window is visible (GTK# repainting needlessly maybe?).

It would seem like this is primarily an issue with Beagle, or that the Tomboy developers has found a way to eliminate the problem.

- Or that I'm on crack and reading the PowerTop output wrong?

Taking a stand

Posted Nov 26, 2008 8:58 UTC (Wed) by tialaramex (subscriber, #21167) [Link] (4 responses)

Well, a typo seems to have slipped into your comment, eliminating the key figure you were trying to communicate. But assuming it's a very small number, rather than say 10 which would just confirm what I said...

It's likely that this bug only affects Mono programs which use threads and can handle signals (merely dying when sent a signal doesn't require "handling") since the usual problem (seen and fixed in e.g. Python) seems to be that someone couldn't figure out how to reconcile POSIX signals with some Windows inspired threading in their design and resolved to just "poll" for signals. Personally I wouldn't have any confidence in a language runtime built by people who couldn't figure out the Right Thing but then I'm a C programmer so perhaps I'm just being a stick in the mud.

Taking a stand

Posted Nov 26, 2008 9:15 UTC (Wed) by Los__D (guest, #15263) [Link]

Doh, that's what I get for taking time to check something, only to use a few seconds writing... :)

It was around 2 wakeups/second.

I don't know the cause, but let's see if they don't get it fixed.

Taking a stand

Posted Nov 26, 2008 20:40 UTC (Wed) by ebirdie (guest, #512) [Link] (1 responses)

I have been hosting a Windows Server 2003 system running as a virtual machine on KVM. On the Windows system is run a .NET app with mysql backend. The .NET app is said to use threads heavily. The .NET app is having problems handling service requests in https. It is slow and drops connections even with minor load. The problem I have with it is that the developers of the app say that I am using a crappy Open Source virtual machine and not some "professional tool" like HyperV or VMware. :-)

Can anyone say here, could the above, what tialaramex described, have effects on KVM too ie. although there is a Windows system doing the threading and signaling "the right way", the VM hosting Linux kernel could have effect to native .NET runtime? Should I quote these comments from here and ask the same on KVM-devel list?

Taking a stand

Posted Nov 27, 2008 17:30 UTC (Thu) by tialaramex (subscriber, #21167) [Link]

My understanding is that this problem is in Mono, specifically, rather than being related to .NET per se.

Your situation is unfortunate but probably unrelated.

Taking a stand

Posted Nov 27, 2008 4:52 UTC (Thu) by ncm (guest, #165) [Link]

If to be a C programmer is to be a stick in the mud, then to be a C++ programmer is to stick a bee in the mud.