Re: [BK PATCH 2.5] Introduce 64-bit versions of PAGE_{CACHE_,}{MASK,ALIGN}

From: Andrew Morton (akpm@zip.com.au)
Date: Sun Jul 28 2002 - 19:10:48 EST

Linus Torvalds wrote:
>
> ...
> Dream on. It's good, and it's not getting removed. The "struct page" is
> size-critical, and also correctness-critical (see above on gcc issues).
>

Plan B is to remove page->index.

- Replace ->mapping with a pointer to the page's radix tree
  slot. Use address masking to go from page.radix_tree_slot
  to the radix tree node.

- Store the base index in the radix tree node, use math to
  derive page->index. Gives 64-bit index without increasing
  the size of struct page. 4 bytes saved.

- Implement radix_tree_gang_lookup() as previously described. Use
  this in truncate_inode_pages, invalidate_inode_pages[2], readahead
  and writeback.

- The only thing we now need page.list for is tracking dirty pages.
  Implement a 64-bit dirtiness bitmap in radix_tree_node, propagate
  that up the radix tree so we can efficiently traverse dirty pages
  in a mapping. This also allows writeback to always write in ascending
  index order. Remove page->list. 8 bytes saved.

- Few pages use ->private for much. Hash for it. 4(ish) bytes
  saved.

- Remove ->virtual, do page_address() via a hash. 4(ish) bytes saved.

- Remove the rmap chain (I just broke ptep_to_address() anyway). 4 bytes
  saved. struct page is now 20 bytes.

There look. In five minutes I shrunk 24 bytes from the page
structure. Who said programming was hard?

-
-
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/

This archive was generated by hypermail 2b29 : Tue Jul 30 2002 - 14:00:31 EST