On Thu, 14 Apr 2011 10:15:07 +0100, Roger Leigh <rleigh@codelibre.net> wrote: > On Thu, Apr 14, 2011 at 10:44:08AM +0200, Bastien ROUCARIES wrote: > > On Thu, Apr 14, 2011 at 4:20 AM, Karl Goetz <karl@kgoetz.id.au> wrote: > > > On Wed, 13 Apr 2011 10:32:42 +0100 > > > Roger Leigh <rleigh@codelibre.net> wrote: > > > > > >> On Tue, Apr 12, 2011 at 12:38:03PM +0100, Roger Leigh wrote: > > > > > >> Following the discussion yesterday, I'd like to propose doing > > >> something like the example below. It's possible to size a tmpfs > > >> as a percentage of core memory, the default being -o size=50%. > > >> Rather than setting an absolute value, we can size e.g. /run > > >> as a percentage of total memory, which should scale with /run > > >> usage better than a fixed value. > > >> > > >> Proposal: > > > [...] > > >> /run/shm: No default (use general tmpfs default of 20%) > > >> /tmp: No default (use general tmpfs default of 20%) > > > > > > 20% doesn't seem like a lot for /tmp when people try and compile > > > something. While its not something most people end up doing, it does > > > seem odd to make people change their tempfs size before they can start > > > building packages for debian/themselves. > > > just a thought, > > > > And moreover for scientific computation /tmp need to be on an > > harddisk. I do not want my 16GiB matric to go to memory when I have > > only 8GiB of RAM.... > > > > Please do not put /tmp on tmpfs use a bind mount of a rw partition > > If it wasn't already clear, having /tmp as a tmpfs is a > /configurable option/, and it is /not/ the default (except when > root is read-only (ro) in fstab). I think that may have been in response to my suggestion that d-i should set that option in the case when people select a multi-partition install, using some or all of the space for that would have been used for the tmp partition as additional swap. It strikes me that in Bastien's example of having huge arrays on /tmp, that allocating the 16G+ that was being allocated to /tmp as additional swap would likely result in either no change, or in fact a speedup, since the kernel can be more relaxed about pushing the writes out to disk when it's doing it as swap, but I've not tested that, so I may be wrong. If the data he's talking about is at all compressible, adding compcache to the mix might make things much faster for him in this setup, which wouldn't help at all if he was still putting the data on a disk partition based /tmp. We should probably run tests on all these cases that people seem to be blithely assuming would be slower. Having run all my systems with tmpfs /tmp for some time, I've never seen any negative impact, and often it's clearly faster. It also ensures that things like laptops don't need to spin up their drives as often. In short, I'm wondering why we don't just say that the default be to have a tmpfs /tmp, set to be about as big as we would have set it if it was on disk, and backed by enough extra swap to ensure that we're no more likely to run out of RAM, and allow people to switch it off if they don't like it, probably via a debconf question that modifies the choices that we make for partition and swap sizing during installs. The only problem I can see might be that things that munch their way through memory (earlier versions of iceweasel come to mind) will take much longer to bump into limits if we have too much swap, and so will cause machines to grind to a halt as they swap all the drivel they've filled memory with. Not that having less swap made that much less painful -- more recent versions of iceweasel seem rather better though, so perhaps we should not pander to broken software in our choice of swap size. Cheers, Phil. -- |)| Philip Hands [+44 (0)20 8530 9560] http://www.hands.com/ |-| HANDS.COM Ltd. http://www.uk.debian.org/ |(| 10 Onslow Gardens, South Woodford, London E18 1NE ENGLAND
Attachment:
pgpUHonfykpML.pgp
Description: PGP signature