Messages in this thread | | | Date | Sun, 06 Apr 2003 16:26:57 -0700 | From | "Martin J. Bligh" <> | Subject | Re: subobj-rmap |
| |
>> 0-150 -> 150-200 -> 200-300 -> 300-400 -> 400-500 -> 500-999 >> A A A A A A >> B B >> C C C >> D D >> E E >> F F F F F F > > I thought of that but decided it is too simple :) > > A downside with it is that from time to time you need to split or > merge subobjects, and that means splitting or merging the list nodes > linking "rows" in the table above - potentially quite a lot of memory > allocation and traversal for a single mmap().
The amount of work to be done is still fairly small ... and we already do (as far as I can see) *exactly* this already for the existing rb tree. Yes, mmap has a little bit more overhead, but you lose all the per-page stuff, which seems much more efficient to me.
>> We can always leave the sys_remap_file_pages stuff using pte_chains, >> and should certainly do that at first. But doing it for normal stuff >> should be less controversial, I think. > > If you implement the 2d data structure that you illustrated, you have > a list node for each point in the table. > > By the time your subobject regions are 1 page wide, you have a data > structure that is order-equivalent to pte rmap chains, although the > exact number of words is likely to be higher.
Well, yes. Except I hope nobody would want to do that on a per-page basis. If you want that level of granularity, we should just do this for linear objects, and fall back to pte_chains for nonlinear.
Life would be a whole lot simpler if people were willing to specify non-linear VMAs at create time - I don't see that as a big burden, personally. That'd get rid of all the conversion stuff.
M.
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |