Message ID | 1339107871-4487-3-git-send-email-rth@twiddle.net |
---|---|
State | New |
Headers | show |
Am 08.06.2012 00:24, schrieb Richard Henderson: > Signed-off-by: Richard Henderson <rth@twiddle.net> > --- > target-alpha/cpu.h | 11 +++++++++++ > 1 files changed, 11 insertions(+), 0 deletions(-) > > diff --git a/target-alpha/cpu.h b/target-alpha/cpu.h > index 99f9ee1..0d87fa7 100644 > --- a/target-alpha/cpu.h > +++ b/target-alpha/cpu.h > @@ -40,9 +40,20 @@ > > #define TARGET_PAGE_BITS 13 > > +#ifdef CONFIG_USER_ONLY > +/* ??? The kernel likes to give addresses in high memory. If the host has > + more virtual address space than the guest, this can lead to impossible > + allocations. Honor the long-standing assumption that only kernel addrs > + are negative, but otherwise allow allocations anywhere. This could lead > + to tricky emulation problems for programs doing tagged addressing, but > + that's far fewer than encounter the impossible allocation problem. */ > +#define TARGET_PHYS_ADDR_SPACE_BITS 63 > +#define TARGET_VIRT_ADDR_SPACE_BITS 63 > +#else > /* ??? EV4 has 34 phys addr bits, EV5 has 40, EV6 has 44. */ > #define TARGET_PHYS_ADDR_SPACE_BITS 44 > #define TARGET_VIRT_ADDR_SPACE_BITS (30 + TARGET_PAGE_BITS) > +#endif > > /* Alpha major type */ > enum { This looks fishy to me... why should the kernel use a bigger address space than hardware? For arm on x86_64 such a workaround was not necessary iirc. Andreas
On 2012-06-12 07:12, Andreas Färber wrote: > This looks fishy to me... why should the kernel use a bigger address > space than hardware? For arm on x86_64 such a workaround was not > necessary iirc. I can tell you what I observe. That with a certain sequence of allocations the x86_64 kernel will quit accepting an address "near" (1<<38) as a hint for where to allocate memory and begin returning an addresses near (1<<48). Further, the logic in find_mmap_vma tries about 5 times (with different hints) to get a target-page-aligned address at a lower address, all of which fail: the kernel continues to return the (1<<48) address. At which point one wonders why we should keep refusing the (1<<48) address when the target is in fact 64-bit capable. I believe the host vs target page size difference plays a part in this, which is why you wouldn't see this on arm. All of the other targets with page size larger than 4k are 64 bit, and set TARGET_VIRT_ADDR_SPACE_BITS to 64. So Alpha was unique in being an 8k page size with T_B_A_S_B < 48, and so probably unique in being able to tickle this problem. r~
On 12.06.2012, at 16:27, Richard Henderson <rth@twiddle.net> wrote: > On 2012-06-12 07:12, Andreas Färber wrote: >> This looks fishy to me... why should the kernel use a bigger address >> space than hardware? For arm on x86_64 such a workaround was not >> necessary iirc. > > I can tell you what I observe. That with a certain sequence of > allocations the x86_64 kernel will quit accepting an address "near" > (1<<38) as a hint for where to allocate memory and begin returning > an addresses near (1<<48). Hrm, does -R work for you? :) Alex
On 2012-06-12 07:53, Alexander Graf wrote: > > > On 12.06.2012, at 16:27, Richard Henderson <rth@twiddle.net> wrote: > >> On 2012-06-12 07:12, Andreas Färber wrote: >>> This looks fishy to me... why should the kernel use a bigger address >>> space than hardware? For arm on x86_64 such a workaround was not >>> necessary iirc. >> >> I can tell you what I observe. That with a certain sequence of >> allocations the x86_64 kernel will quit accepting an address "near" >> (1<<38) as a hint for where to allocate memory and begin returning >> an addresses near (1<<48). > > Hrm, does -R work for you? :) Lol. Actually I've tried it a couple of times: -R 32G. And, no, it doesn't work very well. ;-) r~
On 12.06.2012, at 16:57, Richard Henderson <rth@twiddle.net> wrote: > On 2012-06-12 07:53, Alexander Graf wrote: >> >> >> On 12.06.2012, at 16:27, Richard Henderson <rth@twiddle.net> wrote: >> >>> On 2012-06-12 07:12, Andreas Färber wrote: >>>> This looks fishy to me... why should the kernel use a bigger address >>>> space than hardware? For arm on x86_64 such a workaround was not >>>> necessary iirc. >>> >>> I can tell you what I observe. That with a certain sequence of >>> allocations the x86_64 kernel will quit accepting an address "near" >>> (1<<38) as a hint for where to allocate memory and begin returning >>> an addresses near (1<<48). >> >> Hrm, does -R work for you? :) > > Lol. > > Actually I've tried it a couple of times: -R 32G. 32G is way too much. Do you have to preallocate such a big address space? Usually 1G should be good enough for most programs, no? Alex > And, no, it > doesn't work very well. ;-) > > > r~
On 2012-06-12 08:11, Alexander Graf wrote: > 32G is way too much. Do you have to preallocate such a big address > space? Usually 1G should be good enough for most programs, no? The default start to .text is 6G for alpha executables, so anything less than that + reasonable room will fail for obvious reasons. One would think that e.g. 8G would be good enough, giving 2G above the executable for brk and shared library mapping, but... failure. Alternately, there's some other problem with -R that needs to be investigated. That said, problems with ld.so erroring out with ENOMEM went away with this patch, so... r~
diff --git a/target-alpha/cpu.h b/target-alpha/cpu.h index 99f9ee1..0d87fa7 100644 --- a/target-alpha/cpu.h +++ b/target-alpha/cpu.h @@ -40,9 +40,20 @@ #define TARGET_PAGE_BITS 13 +#ifdef CONFIG_USER_ONLY +/* ??? The kernel likes to give addresses in high memory. If the host has + more virtual address space than the guest, this can lead to impossible + allocations. Honor the long-standing assumption that only kernel addrs + are negative, but otherwise allow allocations anywhere. This could lead + to tricky emulation problems for programs doing tagged addressing, but + that's far fewer than encounter the impossible allocation problem. */ +#define TARGET_PHYS_ADDR_SPACE_BITS 63 +#define TARGET_VIRT_ADDR_SPACE_BITS 63 +#else /* ??? EV4 has 34 phys addr bits, EV5 has 40, EV6 has 44. */ #define TARGET_PHYS_ADDR_SPACE_BITS 44 #define TARGET_VIRT_ADDR_SPACE_BITS (30 + TARGET_PAGE_BITS) +#endif /* Alpha major type */ enum {
Signed-off-by: Richard Henderson <rth@twiddle.net> --- target-alpha/cpu.h | 11 +++++++++++ 1 files changed, 11 insertions(+), 0 deletions(-)