Messages in this thread | | | Date | Thu, 21 Jan 1999 03:33:47 -0800 | From | "David S. Miller" <> | Subject | Re: arca-vm-26 |
| |
Date: Thu, 21 Jan 1999 12:22:10 +0100 (CET) From: Andrea Arcangeli <andrea@e-mind.com>
Really I think that for the long run I should start dropping the cache and buffer hashes replacing them with RB-trees to work fine everywhere without waste some base memory with fuzzy hash tables. I think that doing that everything should scale _far_ better also under the scenario you are describing.
Comments from David? (note RB-trees != AVL ;).
If the page cache hash was 1 chain per system page, people would eat memory scaled to how much memory they have. And you approach ~O(1) access time with a not-too-stupid hash. At worst you eat a cache line miss, and this is service on the order of 24 cpu cycles on most modern machines where you'd have a lot of memory so...
Anyways, thats my position, and I'd be thinking about this sort of stuff for 2.3.x, not now.
Another stupid idea I had, which wasted a lot of memory but could remove a lot of buffer.c code and make things snappier, put MAX_BUF_PER_PAGE buffer heads at the end of struct page, use them when doing page I/O. Zero race conditions, no funny buffer unused and reclaim list races and synchronization, etc. Also each of these static per-page buffer heads have the appropriate pointers and some other state setup already, so you don't need to do much to get an I/O out the door.
But like I said, this is stupid, especially right now because the buffer head structure is a little sizable. If someone trimmed them down a lot and perhaps changed them to really be "I/O tags" then this scheme may make more sense. Even nicer would be if these I/O tags used an iovec[] so a lot of state is redundant in the page I/O case, hint hint :-)
Later, David S. Miller davem@dm.cobaltmicro.com
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |