Subject: Re: GCC3.3.1 switch coming soon.
To: Andrew Brown <atatat@atatdot.net>
From: enami tsugutomo <enami@sm.sony.co.jp>
List: tech-kern
Date: 09/03/2003 12:21:35
Andrew Brown <atatat@atatdot.net> writes:

> i have a patch that (i think) deals with this.  it implements a
> UVM_ET_STACK flag (and adds the transitory VMCMD_STACK and
> UVM_FLAG_STACK flags), and then the merge code refuses to merge
> "stack" with "non-stack" entries.  it's possible on the alpha (where
> the user's stack is not at the top of the user's vmspace) to mmap a
> chunk of space and have it merged with the top end of the stack.

BTW, does just separating map entry help something?  or, not just it?

> >> it also looks like the patch drops some of the required changes to
> >> deal with topdown...
> >
> >where, where? :)
> 
> i'm not sure.  i think i was half asleep when i read your code the
> first time.  i certainly had not had enough coffee.  lemme try to
> absorb it again.  :)

One question about uvm_map_findspace() is that when topdown code is
integerated, it is changed not to call pmap_prefer and not to adjust
alignment for the given hint even if UVM_FLAG_FXIED is not specified.
Is this an intentional change?

> one thing i was considering, though, is pulling the merge code *out*
> and stuffing it into a separate function.  that would make uvm_map()
> shorter, and merging could be done at other places, too (eg, in stack
> allocation/deallocation).

Another thing is map hint (for lookup and free space).  It looks like
it is not used effectively when doing mmap.

enami.