bug-hurd
[Top][All Lists]
Advanced

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

Re: [bug #17346] GNU mach can't handle 4GB memory


From: Samuel Thibault
Subject: Re: [bug #17346] GNU mach can't handle 4GB memory
Date: Mon, 20 Nov 2006 14:31:50 +0100
User-agent: Mutt/1.5.11

Constantine Kousoulos, le Mon 20 Nov 2006 16:15:53 +0200, a écrit :
> All the above solutions aim to make Mach unaware of any memory 
> above 1 GB. Isn't it possible to utilise all the memory?

It's difficult and bug-prone.

> Why don't we make Mach's kernel address space larger so that the 
> whole memory can fit inside it? Mach's virtual address space is 4 
> GB big according to this entry in gnumach/i386/i386/vm_param.h: 
> #define VM_MAX_KERNEL_ADDRESS ((vm_offset_t) 0x40000000)).

Nope, that's 1GiB.

> Why not enlarge kernel space virtual memory and decrease user 
> space virtual memory in order to directly map the whole physical 
> memory in kernel address space.
> So, we could add some configure switches to enable a 1-3 or a 2-2 
> or a 3-1 memory ratio, depending on the desired setup.

You can tune VM_MAX_KERNEL_ADDRESS and LINEAR_MIN_KERNEL_ADDRESS if you
want to do so, yes, but that's only pushing the limit a bit farther.

Moreover, people like Marcus would tell you that the algorithms that
Mach uses for handling memory are just not tune for using so much
memory, so it's a bit pointless.

> In addition to the above, we would also have to use the already
> proposed solution to cut off some memory that Mach can't handle. For
> example, if someone has 4 GB of memory and has setup the kernel for
> a 3-1 ratio (that is 3 Gigs in kernel space), there would have to be
> something like this in model_dep.c:
> 
> phys_first_addr = 0;
> #ifdef CONFIG_3_TO_1_MEM_RATIO
> if (boot_info.mem_upper>0x200000)
>       phys_last_addr = 0x200000
> else
>       phys_last_addr = 0x100000 + (boot_info.mem_upper * 0x400);

I'm against this change: in what I proposed, the limitation is 4GiB,
because that's what can be adressed without PAE anyway. There's no need
to put any other limit here.

Instead, you just need to tune VM_MAX_KERNEL_ADDRESS and
LINEAR_MIN_KERNEL_ADDRESS.

> Is this solution sound? I haven't tested it because i don't have a 
> computer with more than 1 GB of memory.

So why do you bother ? ;)

> I also don't know how a decrease in user space virtual memory will
> affect the performance of GNU/Hurd.

Depends on what you do. Unless you work on big images in gimp or stuff
like this, you don't need to care.

Samuel




reply via email to

[Prev in Thread] Current Thread [Next in Thread]