Quoting "Neal H. Walfield" <[EMAIL PROTECTED]>:
> My idea is to maintain a ~1GB area of "metadata control space." This
> area, rather than being a one-to-one mapping of memory to backing
> store (as it currently is), would lazily map (via a hash) the metadata
> lazily as it is requested. (The ha
[EMAIL PROTECTED] (Niels Möller) writes:
> > This breaks network transparency, and is a bug in the MK8x versions of
> > the kernel, that had to be fixed in the NORMA versions.
>
> There must be some saner way to solve that problem. For integer
> arguments, the network stubs could integers in some
[EMAIL PROTECTED] (Thomas Bushnell, BSG) writes:
> Roland McGrath <[EMAIL PROTECTED]> writes:
>
> > That's insane. The interfaces on 64-bit machines use 64-bit sizes.
>
> This breaks network transparency, and is a bug in the MK8x versions of
> the kernel, that had to be fixed in the NORMA vers
Roland McGrath <[EMAIL PROTECTED]> writes:
> > The memory size must actually be limited on all architectures, because
> > the interfaces are supposed to be machine independent, which requires
> > the word size of the relevant parameters to be constant.
>
> That's insane. The interfaces on 64-bit
> The memory size must actually be limited on all architectures, because
> the interfaces are supposed to be machine independent, which requires
> the word size of the relevant parameters to be constant.
That's insane. The interfaces on 64-bit machines use 64-bit sizes.
___
Marcus Brinkmann <[EMAIL PROTECTED]> writes:
> The reason for the limit is because the address space on IA32 architecture
> is 32 bit.
The memory size must actually be limited on all architectures, because
the interfaces are supposed to be machine independent, which requires
the word size of th
Nicola Girardi wrote:
If I remember correctly, a guy showed up and offered to write an
ext3 server in a way so that it would not suffer that limit and
maybe allow ACLs, then he went to the background. It would be nice
if he could show up once more and tell us if he's doing any progress.
I'm sti
On Fri, Dec 06, 2002 at 03:53:42PM -0500, Neal H. Walfield wrote:
> 64-bit systems do not necessarily give you 64-bits of virtual address
> space (even discounting the kernel's area). Alpha, for instance, only
> gives you 43 bits. There are real practical reasons for doing this:
> the page tables
On Fri, Dec 06, 2002 at 11:52:52AM -0600, Tom Hart wrote:
>
> Peter 'p2' De Schrijver wrote:
> >
> >On Fri, Dec 06, 2002 at 05:46:13PM +0100, Marcus Brinkmann wrote:
> >>
> >>The reason for the limit is because the address space on IA32
> >>architecture is 32 bit. Now, you _could_ of course change
> I wonder what ideas Neal had, I couldn't find a thread where he described his
> ideas.
My idea is to maintain a ~1GB area of "metadata control space." This
area, rather than being a one-to-one mapping of memory to backing
store (as it currently is), would lazily map (via a hash) the metadata
l
On Fri, Dec 06, 2002 at 01:12:24PM -0600, Tom Hart wrote:
> Doesn't this kind of go against the Hurdish "no arbitrary limits"
> philosophy, ie. no MATHPATHLEN, MAXHOSTLEN, etc.?
>
> I agree that 2^64 bits is amazingly huge. But doesn't this sort of
> assumption tend to lead to problems later on
64-bit systems do not necessarily give you 64-bits of virtual address
space (even discounting the kernel's area). Alpha, for instance, only
gives you 43 bits. There are real practical reasons for doing this:
the page tables become far too deep and costly for no benefit (8k
pages => 13 bits + 10k
I agree that 2^64 bits is amazingly huge. But doesn't this sort of
assumption tend to lead to problems later on down the road?
If I have 99 years of 1024x1024@24 50frames/sec movies, and 32061
terabytes of mail, music and other crap, than I have other problems to
think about.
2^64 is so ab
Marcus Brinkmann wrote:
On Fri, Dec 06, 2002 at 07:02:14PM +0100, Peter 'p2' De Schrijver wrote:
On Fri, Dec 06, 2002 at 11:52:52AM -0600, Tom Hart wrote:
Peter 'p2' De Schrijver wrote:
On Fri, Dec 06, 2002 at 05:46:13PM +0100, Marcus Brinkmann wrote:
The reason for the limit is because th
On Fri, Dec 06, 2002 at 07:02:14PM +0100, Peter 'p2' De Schrijver wrote:
> On Fri, Dec 06, 2002 at 11:52:52AM -0600, Tom Hart wrote:
> > Peter 'p2' De Schrijver wrote:
> > >On Fri, Dec 06, 2002 at 05:46:13PM +0100, Marcus Brinkmann wrote:
> > >>The reason for the limit is because the address space
Peter 'p2' De Schrijver wrote:
On Fri, Dec 06, 2002 at 05:46:13PM +0100, Marcus Brinkmann wrote:
The reason for the limit is because the address space on IA32 architecture
is 32 bit. Now, you _could_ of course change the kernel interfaces to allow
for larger memory objects and only limit mapping
On Fri, Dec 06, 2002 at 11:52:52AM -0600, Tom Hart wrote:
> Peter 'p2' De Schrijver wrote:
> >On Fri, Dec 06, 2002 at 05:46:13PM +0100, Marcus Brinkmann wrote:
> >>The reason for the limit is because the address space on IA32 architecture
> >>is 32 bit. Now, you _could_ of course change the kernel
On Fri, Dec 06, 2002 at 05:46:13PM +0100, Marcus Brinkmann wrote:
> On Fri, Dec 06, 2002 at 11:05:13AM +0100, M. Gerards wrote:
> > Another thing I wonder: Why do memory
> > objects have a maximum size of 4GB? Isn't it possible to create a memory object
> > with the size of the entire store and u
On Fri, Dec 06, 2002 at 11:05:13AM +0100, M. Gerards wrote:
> Another thing I wonder: Why do memory
> objects have a maximum size of 4GB? Isn't it possible to create a memory object
> with the size of the entire store and use mapping windows? (Or am I confused
> again? :)). Can someone please de
> Was there any agreement on how to procced with fixing the 1GB limit?
If I remember correctly, a guy showed up and offered to write an
ext3 server in a way so that it would not suffer that limit and
maybe allow ACLs, then he went to the background. It would be nice
if he could show up once more
Quoting "Alfred M. Szmidt" <[EMAIL PROTECTED]>:
> Was there any agreement on how to procced with fixing the 1GB limit?
> The discussion died of after Marcus reposted a discussion about not
> mapping the whole disk to memory.
>
> Here are the archives of the threads:
> http://mail.gnu.org/pipermai
Was there any agreement on how to procced with fixing the 1GB limit?
The discussion died of after Marcus reposted a discussion about not
mapping the whole disk to memory.
Here are the archives of the threads:
http://mail.gnu.org/pipermail/hurd-devel/2002q4/000135.html
http://mail.gnu.org/pipermail
22 matches
Mail list logo
