Messages in this thread | | | Date | Mon, 7 Apr 2003 00:06:24 +0100 | From | Jamie Lokier <> | Subject | Re: subobj-rmap |
| |
Martin J. Bligh wrote: > 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().
> > For VMAs D & E and A & F it's a no-brainer, > > but for Oracle shared memory you shouldn't > > assume that you have any similar mappings > > 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.
To me this suggests that the 2d data structure could be designed carefully, so that in the extreme case it gracefully _becomes_ rmap chains. For memory efficiency you'd need to pack together multiple list nodes into a single cache line - the same tricks used to minimise rmap memory consumption.
I'm not convinced this is the best data structure, but it does seem to suggest the possibility of a hybrid which gives the best of both objrmap and rmap data structures.
-- Jamie - 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/
| |