2012/6/1 Goswin von Brederlow wrote: > All the complaints about /tmp as tmpfs come down to one simple issue: > The size of the tmpfs isn't chosen well.
Mounting /tmp to tmpfs not just breaks a lot of apps and reduces system stability, but it actually does nothing else. You get no benefits from /tmp being on tmpfs. That's the complaint: the change makes something bad and nothing good. > Even without load it is much faster because fsync() becomes a NOP. Yes, it is. So it's a good idea to use tmpfs for some apps, that heavily use fsync() on files that fit in RAM. But... wait... no app is heavily using fsync() on files in /tmp. So it's useless to put /tmp on tmpfs. > It also saves on wear of the disk if the files are small and short > lived, like temp files for gcc. I guess you talk about SSD-like disks. Then... 1. short-lived files remain in cache and don't hit the disk. 2. gcc does not use fsync, does it? 3. gcc with -pipe option does not use /tmp 4. if you manually build something, you can add -pipe option to CFLAGS 5. if you build a package, you can add it to global build options 6. this doesn't matter, since pretty much nobody builds apps on SSD disks So this is not even a corner case. :) >> - There's not enough space, so the system starts swapping, >> including some apps. > > Which happens regardless wether tmp is tmpfs or a real filesystem. > The more IO there is the more likely some app gets swapped out. No. I checked that. If you have e.g. 50% of free ram then whatever files you read/write other apps won't get swapped, zero swap usage. But if you start writing large files to tmpfs you get swapping. > With tmps that instantly frees up all the memory and swap used by the > file. With a real FS the file data remains in the dirty cache until such > a time as the disk has cought up with writing it all and then it is > thrown away. So potentially memory is freed up much later. Actually cache also frees all the memory instantly on delete, but may delay writing to disk. So only a few kilobytes of metadata are not freed. >> Yes because writing that on disk will only block the thread performing the >> write, not every thread that tries to allocate memory. > > Wrong. Not that much. > The thread doing the write will just write to cache and not block > at all. That is until you run out of cache. Until you run out of dirty_ratio, which is usually less than entire cache. :) > No, tmpfs will be swapped out if you don't use a file for a while but > something else uses memory, including IO caching. It won't, I tried. I put a few hundreds MB on tmpfs and started reading and copying gigabytes of files, tar/untar archives. I was still getting no swap usage. As long as there's enough RAM they don't get swapped. >> I'm asking for *popular* apps, that create files in /tmp, *never put >> large files* there, and become *noticeably* faster with /tmp on tmpfs? > > gcc, ocamlopt, mc, lintian Which of them becomes faster with /tmp on tmpfs? Can you suggest a use case, that I can test with /tmp on disk and on tmpfs myself and see them becoming faster? -- Serge -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/caovenepfrzmzzppsux8fib9g0ce-gnoum-mdkzn2nzkyxfw...@mail.gmail.com