Gentoo Logo
Gentoo Spaceship




Note: Due to technical difficulties, the Archives are currently not up to date. GMANE provides an alternative service for most mailing lists.
c.f. bug 424647
List Archive: gentoo-amd64
Navigation:
Lists: gentoo-amd64: < Prev By Thread Next > < Prev By Date Next >
Headers:
To: gentoo-amd64@g.o
From: Richard Freeman <rich@...>
Subject: Re: tmpfs help
Date: Wed, 13 Feb 2008 14:42:14 -0500
Volker Armin Hemmann wrote:
> emm, no.

Look, if you're not going to actually respond to something, then either 
don't reply or at least don't quote it.  One-liners really aren't 
helpful - this isn't mean to be a flame-war over disk-fs vs disk-swap. 
I'm as interested as anybody to understand the pros/cons of both, but 
let's keep it civil and about finding answers, not beating our chests...

> 
> Not real benchmarks. But kdepim with enablefinal, 1gb of ram and -j2 several 
> hours. With j1 2h.
> .
> kdepim with 2gb of ram and j2 30m
> Just because first case swap storn, last case no swap at all.

Well, sure.  But that isn't apples to apples.  And even with more RAM 
you might have a performance difference due to disk-thrashing.

I'll see if I can do some benchmarking between disk and swap.

> 
>> Again, tmpfs doesn't "reserve" memory - it uses memory - just like
>> cache/buffers.
> 
> but while cache/buffers can be discarded when the ram is needed, tmpfs has to 
> be shoved into butt-slow swap.

It can only be discarded after it is flushed.  Just like swap.  The only 
difference is when the flushing occurs.  With files the flushing happens 
right after a write, with swapping it happens when the memory is needed 
for something else.


> 
>>>> I certainly agree that
>>>> swap is slow compared to RAM, but it isn't slow compared to a disk-based
>>>> filesystem.
> 
> yes, yes it is. It is faster to start an app from disk, then to fetch it out 
> of swap. My very personal experience since many many years.
> 

Uh, you do know that when you start an app from disk that the kernel 
just mmaps the file, right?  Then any access to process memory triggers 
a page fault and the page is swapped in.  When you start a program from 
disk it IS swapped to start with - the image on disk is just treated 
like a swap file and the same code is used to read it into memory as any 
other missing page.  The same applies to any other use of mmap.  If you 
go back "many many" years the behavior might have been different, but it 
has been this way for a while.

> 
> your system would feel and act a lot faster if you don't have anything in 
> swap. 'Fine' is good - as long as you don't know the alternative.

How do you know?  What is in the swap?  Maybe it is just pages with 
memory leaks.  If it is never read why would the system be slower?  I 
wouldn't say that performance is any better after a reboot when swap is 
empty.

>> Sure.  Compared to about $1 for 2GB of hard drive space 30 euros is
>> significant.
> 
> don't forget that ram is also roughly 100 times faster than harddisk.

Absolutely.  If I wanted the fastest computer possible I'd have way more 
RAM (and CPU) than I have now.  However, my finances aren't unlimited, 
and I'd rather make the most of what I have than just throw cash at 
problems.  And if I did have more RAM I'd still want to make the most of it.

> 
> you could stop shoving everything in swap - no costs involved and system is a 
> lot faster.
> 

Ok, it is obvious that absent benchmarks that nobody is convincing 
anybody here.  I think that most with a good knowledge of the linux 
kernel would disagree with you.  I don't profess to have that level of 
expertise, but I don't see anything being posted by you which indicates 
why swap should be slower than filesystem access, other than just a 
general statement that swap is "butt slow".

If I can come up with some measurements I'll post them.  My intent isn't 
really to get into a "he said she said" over this.  I'd like to inform 
and be informed, and I'm interested in all experiences although anecdote 
is obviously very limited.
Attachment:
smime.p7s (S/MIME Cryptographic Signature)
References:
tmpfs help
-- Beso
Re: tmpfs help
-- Volker Armin Hemmann
Re: tmpfs help
-- Richard Freeman
Re: tmpfs help
-- Volker Armin Hemmann
Navigation:
Lists: gentoo-amd64: < Prev By Thread Next > < Prev By Date Next >
Previous by thread:
Re: tmpfs help
Next by thread:
Upgrade to KDE 3.5.8 and now sound issues.
Previous by date:
Re: Re: Upgrade to KDE 3.5.8 and now sound issues.
Next by date:
Re: tmpfs help


Updated Jun 17, 2009

Summary: Archive of the gentoo-amd64 mailing list.

Donate to support our development efforts.

Copyright 2001-2013 Gentoo Foundation, Inc. Questions, Comments? Contact us.