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