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.