Re: /tmp as tmpfs and consequence for imaging software
Le Sunday 13 November 2011 16:24:18, Tollef Fog Heen a écrit :
> ]] Bastien ROUCARIES
>
> Hi,
>
> | No it is not true. Science and imaging software are better to use true
> | disk baked file. For instance, if I want ot invert a big matrix they
> | are pretty good algorithm that force only some part of the file to be
> | keep on disk. They known better than kernel when to put somepart on
> | the data on the slow disk.
>
> I doubt the authors of said software is better at writing VMs than the
> kernel authors are. Even if they are as good, the software isn't in a
> position to know the needs ot the whole system, just what the particular
> application needs.
Yes they are particularly for inversion of matrix bigger than memory. And moviemaker software work on file bigger than memory.
Moreover it is not a problem of VM it is a problem of:
- information: kernel lack information on the structure of the problem: how can the kernel known that your piece of data is
positive definite (ftp.numerical.rl.ac.uk/pub/talks/jas.berkeley.28III2007.pdf)
- out of core problem is more than caching.
Why not reverse the argument. Desktop does not fill all the need.
>
> | Using tmpfs under /tmpfs you break assumptions on the life expendancy
> | of memory object.
>
> How is this broken? It's not like /tmp is magically cleaned more often
> just because it's a tmpfs.
No but offlining is not made by application request but by kernel. It is fine in lot of case but not for all the case.
> | And you slow down this kind of software (that work perfecly for 40
> | years).
>
> If the architecture of a piece of software is the same as it was 40
> years ago, it's not particularly well adapted to today's machines, since
> it won't know how to take advantage of virtual memory, multiple cores,
> etc.
Not sure for instance see http://www.tau.ac.il/~stoledo/taucs/ or high performance eigen solver have not been updated since 15
years. But work well and are efficient.
Moreover the tmpfs solution has no quota like on disk file and this could lead to dos (see
http://0pointer.de/blog/projects/plumbers-wishlist-2.html for a solution and they are recent post on lkml).
The problem is that you propose band aid and not long term solution. Apps known better when kernel theirs need.
To my point of view we need:
- a temp standard path cleared each boot (/tmp). Whether it is file backed or memory backed is implementation dependant
- a temp standard path for longer use (/var/tmp). It is file backed.
- a temp standard path cleared each boot but file backed /var/tmp/nonpersistant
The last point is missing and it is a pain.
Bastien
> Cheers,
Reply to: