On Fri, 01.06.12 16:19, Richard W.M. Jones (rjones@xxxxxxxxxx) wrote: > On Fri, Jun 01, 2012 at 11:05:26AM -0400, Gregory Maxwell wrote: > > On Fri, Jun 1, 2012 at 9:50 AM, Gerry Reno <greno@xxxxxxxxxxx> wrote: > > > So everyone needs to go out and buy twice as much RAM so F18+ can run /tmp as tmpfs without causing memory shortfalls > > > for everything else they do. > > > That's crazy. > > > > Thats not true (and I've used tmpfs for tmp for years, so I'm speaking > > from experience)— tmpfs is backed by swap on demand. Just add the > > space that you would have used for /tmp to your swap. > > The *default* limit for tmpfs is half of physical RAM (swap is not > counted). So *if* tmp-on-tmpfs is left at the defaults then > increasing physical RAM might be necessary. I haven't bothered to > look at how tmp-on-tmpfs is implemented in systemd though. I think most folks here really misunderstand what tmpfs is. It's not actually strictly RAM that is used for it, it's *pageable* memory after all. tmpfs is basically RAM preferred, and swap it if we are under pressure. ext3 otoh means must be on disk in the end, but cache in RAM as much as you want. The difference here is hence not really whether things go to disk eventually or not, or whether this takes away precious RAM, because both use disk and both can use RAM. The difference is that the kernel is relieved from the requirement to guarantee integrity on disk, and to write everything to disk ultimately at all if it doesn't otherwise need to. And that's what makes things a bit faster, and reduces general IO load and wakeups. Beyond that it's also kind of nice that this way stuff from /tmp is allocated from a different pool as the rest of the OS so that we can easily apply different limits, but that's just a nice side benefit. I think most of the noise in this flame thread is due to a misunderstanding how modern memory management works and the assumption that having an explicit size limit on /tmp was a bad thing, even though it actually is a good thing... In fact, we need much stronger limits than what tmpfs currently provides: per-user limits on the usage of /tmp. But that's something for the future... Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
