Messages in this thread | | | Date | Fri, 16 Oct 2009 01:21:14 +0100 (BST) | From | Hugh Dickins <> | Subject | Re: [PATCH 7/9] swap_info: swap count continuations |
| |
On Thu, 15 Oct 2009, David Rientjes wrote: > On Thu, 15 Oct 2009, KAMEZAWA Hiroyuki wrote: > > Hmm...maybe I don't understand the benefit of this style of data structure. > > > > Do we need fine grain chain ? > > Is array of "unsigned long" counter is bad ? (too big?) > > I'm wondering if flex_array can be used for this purpose, which can store > up to 261632 elements of size unsigned long with 4K pages, or whether > finding the first available bit or weight would be too expensive.
When flex_arrays were first mooted, I did briefly wonder if we could use them instead of vmalloc for the swap_map; but no, their interface would slow down scan_swap_map() unacceptably.
Extensions of the swap_map are a different matter, they are seldom referenced, and referenced just an item at a time: much better suited to a flex_array. And looking at Jon's Doc, I see they're good for sparse arrays, that would suit swap_map extensions very well.
However... that limit of 261632 elements rules them out here (or can we have a flex_array of flex_arrays?), and the lack of support for __GFP_HIGHMEM is disappointing - the current implementation of swap count continuations does use highmem (though perhaps these pages are so rarely needed that it actually doesn't matter).
It seems that the flex_array is a solution in search of a problem, and that the swap_map extension is not the right problem for it.
Hugh
| |