Looking for a good portable linux system
Mark Komarinski
mkomarinski at wayga.org
Mon Dec 20 11:16:01 EST 2004
On Mon, Dec 20, 2004 at 10:57:52AM -0500, Derek Martin wrote:
> On Mon, Dec 20, 2004 at 10:29:37AM -0500, Bruce Dawson wrote:
> > No. This can't be a dedicated-task system. Also, the app uses things
> > like cron and sendmail to exchange survey data with a satellite - which
> > unfortunately needs to be done via email.
>
> Personally, I think running slocate via cron is a waste of time on a
> personal machine. I think you can avoid that particular problem by
> just removing it from cron. If you use locate, then when install a
> bunch of new software, or whatever, you can always run slocate
> manually at a more convenient time. To be honest though, I never use
> locate, so for me it's pretty much pointless to have the cron job.
I just use find. But I guess that just makes me old school.
> > I was just using slocate as an example to give people an idea of what
> > I'm up against without having to describe the entire app.
>
> If you have other cron jobs that are like slocate, that you need to
> run, a dual proc system may be of only limited help. If your cron
> jobs are I/O intensive, and your application is I/O intensive, then
> your disks may be your bottleneck. I don't know too much about
> hyperthreading CPUs, but it seems like that might be sufficient to
> remedy the kinds of problems you're trying to counteract. I believe I
> heard that linux had hyperthreading support before Windows did... But
> I could be mistaken. ;-)
Here's what I've been able to put together about hyperthreading.
But someone out there smarter than me might have a different answer.
Hyperthreading uses two execution pipelines, but shares L1/L2 cache. So
if the apps share some of the same memory and is CPU-bound, you'll see
a performance benefit, since the two threads can hit L1/L2 cache.
So what happens when you run two different apps? One app has a cache miss
which forces the CPU to go back out to memory, fill the cache, then return
the data to the CPU. Then the *other* execution pipeline wants something
out of memory, can't find it in the cache, and so on.
-Mark
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://mail.gnhlug.org/mailman/private/gnhlug-discuss/attachments/20041220/ba943269/attachment.bin
More information about the gnhlug-discuss
mailing list