Mitch Crane wrote:
OIC, so you're saying that a single request can result in several page
accesses.. turning into several io's. that's a little bit worse than
I was hoping.
Yes. It is a linked list (but shouldn't be that long), but you are
traversing it and by doing so you will end up by replacing the page.
So a more optimized version would keep the hash map and
linked list in core, and the cache entries itself on our block device?
Is there a logical place to split those allocations?
In my prototype I had the item meta-data in memory, and stored the data
for the least frequently used items on disk. To save even more space in
memory you could also store the key itself on ssd and just keep the
complete hash value for the key in memory and only page in the item if
the key hash is equal....
To do so you need to modify the item structure itself, and that is what
we are doing in the engine branch. I have started to redo the tree so
that it'll be easier to merge changes between the two trees, so it's not
up to date right now.
Cheers,
Trond
