[2/9] alpha-linux-user: Work around hosted mmap allocation problems

Signed-off-by: Richard Henderson <rth@twiddle.net>
---
 target-alpha/cpu.h |   11 +++++++++++
 1 files changed, 11 insertions(+), 0 deletions(-)

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~