[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Default size limits for /run (/var/run) and /run/lock (/var/lock)

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

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

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: pgpkKHID0yMJD.pgp
Description: PGP signature

Reply to: