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?
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
