> I'm not sure the page cache will help you a lot unless you reference just a > small portion of your cache because this is how it works: > > you send in a key, and the server will generate a hash value from the key. > It will then jump into the gigant hash map (you'll have this in the memory), > and there it will find the pointer to a linked list (or null if no items > with a key that hash to this value exists). > > All items in this linked list will be stored in the section you mapped from > the device, and due to the fact that it is a linked list of items with the > same _hash_ value, they may _not_ be stored in the same _slab_ (different > sizes) and would therefore be on different memory pages on disk... > > makes sense?
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. 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? thanks! Mitch.
