Joe Sloan wrote:
Aaron Kulkis wrote:
Sloan wrote:
Gary Baribault wrote:
And just for your general information, with Beagle installed, SuSE was using 1.5Gig of Memory and 256Meg of Swap.
After removing Beagle and a reboot, I have 887Meg free and no swap used, I would think that Beagle qualifies as a HOG. I don't care what it offers as an advantage, it isn't worth that, (I have about 2 Gigs of EMail it was indexing)
Well, I've never rebooted after nuking beagle, but I've always noticed similar benefits -
Unfortunately beagle got my attention because whilst playing quake 3 arena online I would experience annoying pauses during game play, lasting up to half a second. Naturally I would often be fragged during these comatose periods. Removing beagle and zmd brings back silky smooth performance. It would be great if the beagle devs could take a page from the boinc playbook, and only use CPU when it is not being used by other apps. That's done by the scheduler in the kernel, not the app. And it's not just CPU usage... beagle stresses the entire system (especially clogging up filesystem I/O with a flood of outstanding requests which keep the disk-heads moving all the time, and introducing a big delay in disk I/O responsiveness for any other process (both already running and new processes).
If you look at boinc, it's possible to do this with clever programming, completely in userland. When we've run boinc, the load average on the box rises to the point that you'd think the box is in trouble, judging from load average indications, but then you notice that everything is still quite responsive.
"clever programming" is something I was a big fan of when I was in high school and college in the 1980's. Then I got out into the real world, where "clever code" usually translates very quickly into "unmaintainable code." I used to LOVE programming in assembly language. And it would be very good if the world was static and unchanging. HOWEVER...the real world is constantly changing, and code written in assembly langauge has a very VERY short lifespan -- making it suitable only for embedded systems...and only then on short production runs for items which you WILL NOT be producing the product 2 years later. (or if you're doing something with really REALLY unusual constraints, like trying to fit a program and it's data into the on-board memory of a Motorola 68HC11 so that you have full use of ALL of the I/O ports as such, without having to use any as address/data busses.
I haven't looked at the boinc code, but it's not new (I ran such tests in 2002 or so), and it's cross platform code, nothing linux specific there and all userspace, no kernel code.
Joe
-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org