Kinkie wrote:
Though there is a potential loss of disk IO efficiency when alignments of
the data portion are not on the 4096/8192 disk chunk borders. The few dozen
bytes of overhead difference in the disk and memory nodes are annoying.
A possibility is to detach the data from the data structures needed to
access them, in much the same ways filesystems do.
But this is better tested out first in a specialized environment (e.g.
in a mem-based cache_dir implementation).
That pretty much what I was thinking. Taking on the inode model. Where N
mem_node_meta objects are allocated in a sequential page slab, which
would be allocated and swapped in/out as a chunk anyway. That maintains
locality of the meta data, which same as now contains a ptr to page of data.
This needs a bit more thought and figuring why mem_node has a fixed data
buffer of its own AND a StoreIOBuffer pointing at a dynamic amount of
MemBuf. I have not looked at this past seeing the fields of mem_node and
having the idea that it holds the in-memory object in a sequence of data
pages.
Rough ideas on top of that:
Going by the size of mem_node and StoreIOBuffer it looks like we can
squeeze each meta slab into 256 bytes. Or with padding can have 2-3 per
KB easily.
I'm thinking now of an average object <16KB taking 3x mem_node_meta and
3x dynamically allocated pages for data 2x 4KB and the third 8KB aligned.
So a minimum object takes 1x4KB pages as now, average object takes 4x4KB
data pages and 256B-1KB of meta. Larger objects get another
mem_node_meta slab and so the sequence repeats.
Amos
--
Please be using
Current Stable Squid 2.7.STABLE7 or 3.0.STABLE20
Current Beta Squid 3.1.0.15
