[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
- [bug #17346] GNU mach can't handle 4GB memory, Samuel Thibault, 2006/11/15
- Re: [bug #17346] GNU mach can't handle 4GB memory, Constantine Kousoulos, 2006/11/20
- Re: [bug #17346] GNU mach can't handle 4GB memory, Samuel Thibault, 2006/11/20
- Re: [bug #17346] GNU mach can't handle 4GB memory, Constantine Kousoulos, 2006/11/20
- Re: [bug #17346] GNU mach can't handle 4GB memory, Samuel Thibault, 2006/11/20
- Re: [bug #17346] GNU mach can't handle 4GB memory, Constantine Kousoulos, 2006/11/20
- Re: [bug #17346] GNU mach can't handle 4GB memory, Samuel Thibault, 2006/11/20
- [bug #17346] GNU mach can't handle 4GB memory, Samuel Thibault, 2006/11/26