| 1 |
Volker Armin Hemmann wrote: |
| 2 |
> |
| 3 |
> with your small amount of memory tmpfs hurts you more than helps you. The |
| 4 |
> small compilations might to be sped up. But what about the big ones? |
| 5 |
> |
| 6 |
> Slow downs, because swap is used. Big slow downs, because swap is horribly |
| 7 |
> slow. |
| 8 |
|
| 9 |
Do you have benchmarks to support this? |
| 10 |
|
| 11 |
Why would swap be any slower than compiling to disk? If the compilation |
| 12 |
generates 6GB of files and you have 512MB of spare RAM, then most likely |
| 13 |
5.5GB of that stuff will have gotten written to disk during the course |
| 14 |
of compilation - with very opportunistic writing. The last 512MB of |
| 15 |
data will probably be deleted from RAM before it ever gets written. |
| 16 |
|
| 17 |
On the other hand, without a tmpfs then all 6GB is guaranteed to be |
| 18 |
written to disk. Any files that are created and deleted 10 seconds |
| 19 |
later will be written to disk with a guaranteed sync. Every write will |
| 20 |
get synced withing a few seconds. |
| 21 |
|
| 22 |
I would think that swap would be more efficient than a million files on |
| 23 |
a filesystem. The kernel can flush tmpfs pages at any time - and it |
| 24 |
doesn't have a compulsion to flush out writes immediately since there |
| 25 |
isn't any sense of permenancy to the data. |
| 26 |
|
| 27 |
> Slow downs in daily usage because space that could be used for |
| 28 |
> cache&buffers is wasted for tmpfs. |
| 29 |
|
| 30 |
As opposed to wasting all your RAM on cache&buffers to hold all those |
| 31 |
files being accessed? During compilation that RAM is going to be |
| 32 |
heavily used - no getting around that. Once you're done any files left |
| 33 |
sitting on a tmpfs will just get paged out until accessed. They |
| 34 |
shouldn't really use any RAM at all. Even if those files were on disk |
| 35 |
they would consume RAM in the form of caching until they're considered |
| 36 |
unneeded. |
| 37 |
|
| 38 |
Basically tmpfs lets the kernel have more flexibility in memory |
| 39 |
management, while with disk-based temporary filesystems you're forcing |
| 40 |
the kernel to treat temporary data the same way you'd treat more |
| 41 |
critical files. |
| 42 |
|
| 43 |
I know that this is a bit of a religious debate, however I believe it is |
| 44 |
full of misconceptions. I'd be very interested in actual benchmarks - |
| 45 |
although I'm sure this stuff isn't easy to test. I certainly agree that |
| 46 |
swap is slow compared to RAM, but it isn't slow compared to a disk-based |
| 47 |
filesystem. Of course adding more RAM will never hurt, but that incurs |
| 48 |
significant cost and you can at least maximize your current hardware |
| 49 |
before investing in more of it. |
| 50 |
-- |
| 51 |
gentoo-amd64@l.g.o mailing list |
Archives