Date: Thu, 30 Nov 1995 11:45:48 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: dyson@FreeBSD.ORG Cc: terry@lambert.org, taob@io.org, freebsd-hackers@FreeBSD.ORG Subject: Re: Increasing size of shared memory segmenty Message-ID: <199511301845.LAA01126@phaeton.artisoft.com> In-Reply-To: <199511300010.AAA04609@dyson.iquest.net> from "John S. Dyson" at Nov 30, 95 00:10:31 am
next in thread | previous in thread | raw e-mail | index | archive | help
> > 32M is smaller than the overall limit, (36 bits? 39 bits?) so you should > > be safe, though if you have several of these, you will probably start > > having problems. > > The limit today is 31 Bits :-(. But the code that I am running today > is 39 Bits with perhaps 40 Bits in the offing. It is unlikely that we > will need to use more than a 31 Bit window on a Pentium :-), but now > at least we will be able to have at least 1Tb files with the merged > VM buffer cache scheme. Any chance for windowed access? I'd like to have a 2^63 sized file. The problem is apparently that the mappings are cached based on the virtual address space, when indirecting them through an offset+range mapping would solve the problem nicely. I realize this means adding a range chain at the top level of the buffer cache in the vnode, but this could be reduced to a single compare and only hit the performance if a bit was set saying that the cache data was indirected, and then only if the file size was greater than the mapping limit (it would let you leave it at 31 bits if you wanted). You'd need to steal a bit in the vnode for this, and set it either on open (put it in the in-core vnode) or steal an inode bit and put it on disk. Obviously, I'd prefer an in-core implementation (I'd like to hang the file locks off the vnode instead of the inode as well, so I have ulterior motives). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199511301845.LAA01126>