On Mittwoch, 13. Februar 2008, Richard Freeman wrote:
> Volker Armin Hemmann wrote:
> > with your small amount of memory tmpfs hurts you more than helps you. The
> > small compilations might to be sped up. But what about the big ones?
> >
> > Slow downs, because swap is used. Big slow downs, because swap is
> > horribly slow.
>
> Do you have benchmarks to support this?

which numbers? that swap is horrible slow compared to ram?

>
> Why would swap be any slower than compiling to disk?  If the compilation
> generates 6GB of files and you have 512MB of spare RAM, then most likely
> 5.5GB of that stuff will have gotten written to disk during the course
> of compilation - with very opportunistic writing.  The last 512MB of
> data will probably be deleted from RAM before it ever gets written.

think about this: instead of having the compiler in ram and files on disk, you 
have to swap the compiler out, read the files from swap into ram, swap the 
compiler in, do some stuff, repeat. Slowdown.

>
> On the other hand, without a tmpfs then all 6GB is guaranteed to be
> written to disk.  Any files that are created and deleted 10 seconds
> later will be written to disk with a guaranteed sync.  Every write will
> get synced withing a few seconds.

nope. Stuff that is written and deleted some seconds later never hit the disk. 
That is why cache&buffer exist.

>>
>  > Slow downs in daily usage because space that could be used for
>  > cache&buffers is wasted for tmpfs.
>
> As opposed to wasting all your RAM on cache&buffers to hold all those
> files being accessed?  During compilation that RAM is going to be
> heavily used - no getting around that.  Once you're done any files left
> sitting on a tmpfs will just get paged out until accessed.  They
> shouldn't really use any RAM at all.  Even if those files were on disk
> they would consume RAM in the form of caching until they're considered
> unneeded.

cached&buffered information can be discarded anytime if the ram is needed 
elsewhere. tmpfs has to be shoved into swap.


>
> Basically tmpfs lets the kernel have more flexibility in memory
> management, while with disk-based temporary filesystems you're forcing
> the kernel to treat temporary data the same way you'd treat more
> critical files.

with the files on disk, the kernel can hold as much data in ram as he likes 
to. with a big tmpfs (and 512mb out of 1gb) he is always shoving someting 
into swap or get something from there. 

Extreme example?

kdepim with the enablefinal flag. On amd64 every single gcc instance needs 
~900mb at two points of compilation. With 1gb ram and no tmpfs it sucks.

With 1gb ram and 512mb of that reserved for tmpfs, you'll get a swapstorm.

>
> I know that this is a bit of a religious debate, however I believe it is
> full of misconceptions.  I'd be very interested in actual benchmarks -
> although I'm sure this stuff isn't easy to test.  I certainly agree that
> swap is slow compared to RAM, but it isn't slow compared to a disk-based
> filesystem.

really? Every really swapped? IMHO it feels like every single byte is fetched 
by a mule.

 Of course adding more RAM will never hurt, but that incurs 
> significant cost and you can at least maximize your current hardware
> before investing in more of it.

significant costs like 30euros for 2gb?
-- 
gentoo-amd64@g.o mailing list