Skip to Content.
Sympa Menu

sm-discuss - Re: [SM-Discuss] tmpfs

sm-discuss AT lists.ibiblio.org

Subject: Public SourceMage Discussion List

List archive

Chronological Thread  
  • From: Phil/CERisE/KG6MBQ <cerise AT littlegreenmen.armory.com>
  • To: Source Mage Discuss <sm-discuss AT lists.ibiblio.org>
  • Subject: Re: [SM-Discuss] tmpfs
  • Date: Fri, 26 Jul 2002 17:33:31 -0700 (PDT)

Sergey A. Lipnevich said:

> I did test both. Here's why I mentioned rebooting. When
> you untar anything into filesystem, it stays in fs
> cache unless you reboot (or the PC is short on memory,
> or your fs is brain-dead). So, I looked at GKrellM and
> observed that while compiling on reiserfs, the disk
> hits were separated by almost equal periods of silence
> of several seconds: ..|..|..|..|..|..|.. forgive me
> this simplicity ;-)

I would have suspected that cache didn't keep track of deleted
files, although I haven't kept up on the current mechanism. It may be
a worry, I suppose. I presumed that you were deleting the tar as well,
but rebooting should do the trick.

>Then, compiling on tempfs produces
> *much* less disk hits at irregular intervals, so this
> can be labeled as regular PC activity (noise for this
> experiment).

I don't think it can really be considered "noise." The system, as a
whole, must be judged here. There's far too many different components
at work in the kernel, drivers, and file system to assume that anything
isn't caused (even indirectly) from the compilation. The only
acceptable way to test it is overall, averaged performance as a result.

> So, I think GKrellM was showing me disk
> writes of compiled object and executable files
> (mostly). I don't have the numbers saved, but tempfs
> lead was ~45 seconds on a 10 min-magnitude compile.
> In the end, it may also depend on the order of
> experiment, because /usr/include is cached during first
> compilation, and is "already there" on the second.
>
> All in all, you hit disk more when compiling on real
> fs, and there's no reason for this. Also, I think
> multi-threaded compilation on a multi-CPU machine would
> advance tempfs even further.

I'm not as certain about multi-threaded compilation on a multi-CPU
system. I'd tend to say that the factor would be equivalent on both
sides. My system is a multi-CPU system though, and that can certainly
be tested as part of the runs.
It's worth noting though that my concern is more about lower end
systems. The improvement is sure to be an order of magnitude between a
pentium 90 and a dual P-III 500
Your comment about /usr/include is warranted certainly. I suppose a
reboot is necessary after all for fairness, unless there's an easy way
that's guaranteed to flush the cache.

> Cheers to sysadmins :-)!

Hear hear!

-Phil/CERisE






Archive powered by MHonArc 2.6.24.

Top of Page