Subject: Re: struct file reference counts
To: Jaromir Dolecek <firstname.lastname@example.org>
From: David Laight <David.Laight@btinternet.com>
Date: 12/16/2001 19:34:57
> David Laight wrote:
> > IMHO I would have thought that 32bits would be enough...
> Yes, it is more than enough on 32bit archs. Also, 'long' is actually
> 2^32 times bigger than 'int' on lp64 archs, so it's as good
> as reference counter as 32bit long for 32bit archs. All in all,
> 'long' should not be overflowable as reference counter on both LP32 and LP64
My thought was that 32 bits would be enough on an LP64 system, maybe use
64bit on an ILP64 system. Too many other things will explode before you
hit 64k references. I realise that someone once thought '65536 counts
will always be enough' but you do need circa 2^30 processes before
a 32bit count will wrap.
> > I presume you've seem the 16bit counter wrap - with obvious devistating
> > results...
> Yes, I've seen the 16bit counter wrap.
Presumably on something like /dev/null on a process concurrency test of a
server task? (21846 processes, 3 fd per process)
> > However the extra 8 bytes per 'file' is probably a higher cost in kvm.
> Yes, that too.
Also a question of how many cache lines the structure fits it.....
> Furthermore, 64bit arithmetic is costly on 32bit
> archs. For reference counters, it's entrirely supeflouous to have
> 64bit counters on 32bit archs.
And the 16bit arithmetic is also (probably) nasty! Especially is gcc insists
on masking the high bits....
A thought of a cunning plan of wrapping back to 0x80000000 (ie using the
top bit as a 'has wrapped' state), on decrement to 0x80000000 you go and
look for a reference in one of the obvious places if you find one (and there
are plenty out there to find) if not you free the item. But I can't quite
get the number to work without doing a extra compare. (I think you have to
check the decrement at 0x40000000 so it can be set back to 0x80000000.)