lkml.org 
[lkml]   [1999]   [Jan]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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/

\
 
 \ /
  Last update: 2005-03-22 13:49    [W:1.992 / U:0.596 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site