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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
