On Thu, Jul 12, 2012 at 6:43 PM, David Sommerseth <davids@xxxxxxxxxx> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 01/06/12 19:42, Brian Wheeler wrote: >> >> >> On 06/01/2012 12:21 PM, Lennart Poettering wrote: >>> 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 >>> >> >> I understand how memory management works...which is why this seems >> like a terrible idea. >> >> Can you provide numbers that show that there is a speed increase >> with this scheme which offsets the amount of change required to do >> this? I haven't seen anything other than "its faster". >> >> This is change is troublesome for multiple reasons: * It switches >> the semantics of what /tmp is. Its now apparently for small and >> short-lived files. Where small and short-lived are defined based >> on the RAM usage at the time a file is created. Hooray for >> heisenbugs! * everything that did use /tmp now should use /var/tmp >> which means patching a ton of programs and hoping that third party >> applications do the same thing. So the "problem" this fixes with >> /tmp now exists in /var/tmp. * there are no numbers which back up >> the purported benefits * file data gets moved out of RAM (in this >> case, to swap) not when it is convenient for the kernel at a >> potentially idle time but when the kernel is experiencing memory >> pressure. * changing the amount of space available in /tmp means >> screwing with swap files >> >> How is this change a win? > > I sense a long term strategy ... > > a) Move /tmp to tmpfs > b) all programs using /tmp uses /var/tmp > c) all failing programs enforces $TMPDIR to be set to /var/tmp > d) Somebody discovers that /tmp is no longer in use - and propose to > remove /tmp all in all > > But we're just at the beginning... > > Having that said ... I really see some benefits of /tmp on tmpfs, but > for large workloads which depends on /tmp or $TMPDIR it will be a > pain, no matter what, IMO. And it strikes me as interesting that > Solaris have been doing a similar tmpfs approach for years; yet still > the thumb-rule seems to be "get rid of that ram-fs-stuff and put /tmp > on a real drive". And I wonder why........ > > A couple of times (several years ago now), I've experienced /tmp being > filled up with junk - and at that time /tmp was a part of /. And that > caused even more fun challenges. So I started deploying /tmp on a > separate LVM logical volume, with a restricted space. Since that > time, all systems have been running quite stable - despite /tmp > getting filled up from time to time. But that's usually not a problem, > as in worst case that misbehaving program just dies. > > But I'm really curious to see what happens if this happens on a tmpfs > based /tmp. If you have 4GB RAM server and a 4GB swap ... and then a > program hits the system creating 8-9GB of trash in /tmp ... how will > that impact the performance and responsiveness of the overall system? > How will applications reading data from these memory pages being > swapped out behave (in a performance, point of view) Will OOM killer > at some point kick in? And if OOM killer starts, I'm curious which > processes it will pick to kill ... I imagine this to be particular > funny if you're running something RAM intensive, like something Java > based (JBoss anyone?). > Again.. tmpfs is restricted to half the RAM size by default. You can't store 8-9GB of trash.. only 2GB, which might land on swap over time. -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel