| 1 |
On Mittwoch, 13. Februar 2008, Richard Freeman wrote: |
| 2 |
> Volker Armin Hemmann wrote: |
| 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 |
| 7 |
> > horribly slow. |
| 8 |
> |
| 9 |
> Do you have benchmarks to support this? |
| 10 |
|
| 11 |
which numbers? that swap is horrible slow compared to ram? |
| 12 |
|
| 13 |
> |
| 14 |
> Why would swap be any slower than compiling to disk? If the compilation |
| 15 |
> generates 6GB of files and you have 512MB of spare RAM, then most likely |
| 16 |
> 5.5GB of that stuff will have gotten written to disk during the course |
| 17 |
> of compilation - with very opportunistic writing. The last 512MB of |
| 18 |
> data will probably be deleted from RAM before it ever gets written. |
| 19 |
|
| 20 |
think about this: instead of having the compiler in ram and files on disk, you |
| 21 |
have to swap the compiler out, read the files from swap into ram, swap the |
| 22 |
compiler in, do some stuff, repeat. Slowdown. |
| 23 |
|
| 24 |
> |
| 25 |
> On the other hand, without a tmpfs then all 6GB is guaranteed to be |
| 26 |
> written to disk. Any files that are created and deleted 10 seconds |
| 27 |
> later will be written to disk with a guaranteed sync. Every write will |
| 28 |
> get synced withing a few seconds. |
| 29 |
|
| 30 |
nope. Stuff that is written and deleted some seconds later never hit the disk. |
| 31 |
That is why cache&buffer exist. |
| 32 |
|
| 33 |
>> |
| 34 |
> > Slow downs in daily usage because space that could be used for |
| 35 |
> > cache&buffers is wasted for tmpfs. |
| 36 |
> |
| 37 |
> As opposed to wasting all your RAM on cache&buffers to hold all those |
| 38 |
> files being accessed? During compilation that RAM is going to be |
| 39 |
> heavily used - no getting around that. Once you're done any files left |
| 40 |
> sitting on a tmpfs will just get paged out until accessed. They |
| 41 |
> shouldn't really use any RAM at all. Even if those files were on disk |
| 42 |
> they would consume RAM in the form of caching until they're considered |
| 43 |
> unneeded. |
| 44 |
|
| 45 |
cached&buffered information can be discarded anytime if the ram is needed |
| 46 |
elsewhere. tmpfs has to be shoved into swap. |
| 47 |
|
| 48 |
|
| 49 |
> |
| 50 |
> Basically tmpfs lets the kernel have more flexibility in memory |
| 51 |
> management, while with disk-based temporary filesystems you're forcing |
| 52 |
> the kernel to treat temporary data the same way you'd treat more |
| 53 |
> critical files. |
| 54 |
|
| 55 |
with the files on disk, the kernel can hold as much data in ram as he likes |
| 56 |
to. with a big tmpfs (and 512mb out of 1gb) he is always shoving someting |
| 57 |
into swap or get something from there. |
| 58 |
|
| 59 |
Extreme example? |
| 60 |
|
| 61 |
kdepim with the enablefinal flag. On amd64 every single gcc instance needs |
| 62 |
~900mb at two points of compilation. With 1gb ram and no tmpfs it sucks. |
| 63 |
|
| 64 |
With 1gb ram and 512mb of that reserved for tmpfs, you'll get a swapstorm. |
| 65 |
|
| 66 |
> |
| 67 |
> I know that this is a bit of a religious debate, however I believe it is |
| 68 |
> full of misconceptions. I'd be very interested in actual benchmarks - |
| 69 |
> although I'm sure this stuff isn't easy to test. I certainly agree that |
| 70 |
> swap is slow compared to RAM, but it isn't slow compared to a disk-based |
| 71 |
> filesystem. |
| 72 |
|
| 73 |
really? Every really swapped? IMHO it feels like every single byte is fetched |
| 74 |
by a mule. |
| 75 |
|
| 76 |
Of course adding more RAM will never hurt, but that incurs |
| 77 |
> significant cost and you can at least maximize your current hardware |
| 78 |
> before investing in more of it. |
| 79 |
|
| 80 |
significant costs like 30euros for 2gb? |
| 81 |
-- |
| 82 |
gentoo-amd64@l.g.o mailing list |
Archives