Discussion:
first gap in the map
enami tsugutomo
2003-10-26 00:51:48 UTC
Permalink
# moved to tech-perform by request.
what's "first gap case" ?
I mean we don't need to search space in the gap between map start and
first entry in topdown (non-fixed mapping) case.

enami.
YAMAMOTO Takashi
2003-10-26 10:39:00 UTC
Permalink
Post by enami tsugutomo
# moved to tech-perform by request.
what's "first gap case" ?
I mean we don't need to search space in the gap between map start and
first entry in topdown (non-fixed mapping) case.
are you talking about 'first_free' ?

YAMAMOTO Takashi
enami tsugutomo
2003-10-26 22:53:27 UTC
Permalink
Post by YAMAMOTO Takashi
are you talking about 'first_free' ?
No.
Post by YAMAMOTO Takashi
Post by enami tsugutomo
I mean
there is the code to handle the first gap specially only for
non-topdown case but
Post by YAMAMOTO Takashi
Post by enami tsugutomo
we don't need to search space in the gap between map start and
first entry in topdown (non-fixed mapping) case.
so, it would be ok.

btw, is the change in uvmspace_exec() really necessary?

enami.
YAMAMOTO Takashi
2003-10-27 01:18:38 UTC
Permalink
Post by enami tsugutomo
Post by enami tsugutomo
I mean
there is the code to handle the first gap specially only for
non-topdown case but
where? in the patch i posted?
it isn't my intention. maybe a bug.
Post by enami tsugutomo
Post by enami tsugutomo
we don't need to search space in the gap between map start and
first entry in topdown (non-fixed mapping) case.
so, it would be ok.
yes, but it's better not to have such assumptions about
upper layer behaviors, IMO.
Post by enami tsugutomo
btw, is the change in uvmspace_exec() really necessary?
no. thanks for pointing.

YAMAMOTO Takashi
enami tsugutomo
2003-10-27 01:45:06 UTC
Permalink
Post by YAMAMOTO Takashi
Post by enami tsugutomo
Post by enami tsugutomo
I mean
there is the code to handle the first gap specially only for
non-topdown case but
where? in the patch i posted?
it isn't my intention. maybe a bug.
With current implemention, the only real entries are managed in
rbtree, and thus the gap after those entries can be searched by rbtree
walk, right? So, the gap between map start and the first entry needs
to be check specially. The code after /* Check slot before any entry
*/ is the special check (it is necceary for kernel or its sub map).

But for topdown case, the entry there isn't the first entry usually.
And since it should be the last resort in topdown case, the test
should be done after tree walk failed to find space.

But currently `tree walk failed' doesn't mean there was really no
space in the tree (since the walk doesn't test all candidates). So,
fixing this would be a bit hard (possibilly, we want to put the first
gap in the tree also).
Post by YAMAMOTO Takashi
no. thanks for pointing.
Also, uvm_rb_space() doesn't need to handle the entry->next ==
&map->header case specially. return (entry->next->strart -
entry->end); is enough.

enami.
YAMAMOTO Takashi
2003-10-27 03:08:29 UTC
Permalink
Post by enami tsugutomo
With current implemention, the only real entries are managed in
rbtree, and thus the gap after those entries can be searched by rbtree
walk, right? So, the gap between map start and the first entry needs
to be check specially. The code after /* Check slot before any entry
*/ is the special check (it is necceary for kernel or its sub map).
But for topdown case, the entry there isn't the first entry usually.
And since it should be the last resort in topdown case, the test
should be done after tree walk failed to find space.
But currently `tree walk failed' doesn't mean there was really no
space in the tree (since the walk doesn't test all candidates). So,
fixing this would be a bit hard (possibilly, we want to put the first
gap in the tree also).
i got your point. thanks for explanation.
Post by enami tsugutomo
Also, uvm_rb_space() doesn't need to handle the entry->next ==
&map->header case specially. return (entry->next->strart -
entry->end); is enough.
yea, i'm wondering if 'ownspace' is worth to cache..

YAMAMOTO Takashi

Loading...