One word: Eh?
Based on what I did with Nachos it would take only one page table entry *
per page of physical memory; (alternately, the order-0 free bitmap [cw]ould
grow by a factor of sizeof(pointer)), unless you also need a struct task *
that's not present in the struct page. To maintain this you'd only need one
written word per page freed by free_pages_ok or allocated by __get_free_pages
(though the latter function doesn't have the data it would need, so the
stuff in vmalloc.c would have to do it again). Kernel pages (with no virtual
mapping, and thus no way to transparently remap them) and free pages (duh)
would have magic "addresses" for their reverse page table entries, of
course.
> It
> comes up every once in a while, but I'd really like to avoid it if at all
> possible.
Right now I see it as a cheap and elegant solution to the fragmentation
problem which involves low-coefficient O(1) work to maintain and one kbyte
of storage per megabyte of physical memory. My 32M machine can certainly
trade 32k it can't use when it needs it, for 16k (and larger) fragments
on demand...
Keith (been here, done this, graded the papers)