Subject: Re: GCC3.3.1 switch coming soon.
To: enami tsugutomo <enami@sm.sony.co.jp>
From: Andrew Brown <atatat@atatdot.net>
List: tech-kern
Date: 09/16/2003 10:46:45
sorry for the delay...

>> 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?

now that i've picked over your code, i think it won't help, but it
does avoid an entirely different problem (which may just be once of
aesthetics).

that said, i've read over your code more carefully, and i think i see
where the problem is but since your code fixes the problem and
enhances readability at the same time, it would probably be good to
commit it.  thanks.

>> >> 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?

i was specifically avoiding calling pmap_prefer, yes, since
pmap_prefer *currently* only pushes addresses upwards to achieve
alignment.  in the topdown world, one would want the address pushed
down.  i have patches to change pmap_prefer from two arguments to four
(adding topdown and size), but i have to retest them.

as for not adjusting the alignment...i'm not sure i follow you.

>> 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.

that's very possible.

-- 
|-----< "CODE WARRIOR" >-----|
codewarrior@daemon.org             * "ah!  i see you have the internet
twofsonet@graffiti.com (Andrew Brown)                that goes *ping*!"
werdna@squooshy.com       * "information is power -- share the wealth."