Buf cache renovation project
As decided by the junta at BSDcan2008
Attack 1: VREG data from buf to VM
Stuckee: jeffr
- Move the regular file data out of the buffercache, let VM system manage it.
(jeffr: add details)
Attack 2: Syncer to per-{bufobj,mount} threads
Stuckee: ? (phk ?)
- Park a kthread when mounting
- can hold onto mount cred
- can do NFS reconnect
- Responsible for policy of synching for this filesystem instance
- Makes it possible to avoid the "sync entire filesystem" for fs that do not need it.
- Generally only responsible for synching metadata (VM above does data)
Technically, the thread is associated with the bufobj but in practice that is the mountpoint (Relevant for gibbs@'s case)
Attack 3: Unmapped S/G bio
Stuckee: phk, jhb
Strawman for structure:
struct sglist_seg {
vm_paddr_t ss_paddr;
size_t ss_len;
};
struct sglist {
struct sglist_seg *sg_segs;
int sg_nseg;
};
struct bio {
struct sglist biosg;
struct sglist_seg seg0[NBIOSEG];
};Note that vm_page_t is inconvenient to get if you don't already have it. Hence we were talking about passing it down if we already had it since it isn't that cheap to recover if a lower level wants it for some reason. If we have it, then it would be worth passing down (think PAE.. vm_page_t is 4 bytes, paddr is 8 bytes). But if we don't universally have it available at all call sites then don't bother. -Peter
Some hacking is going on in the p4 branch in //depot/user/jhb/bio/... so far there is just the start of a scatter/gather list API. The next step I am working on is replacing the MD _bus_dmamap_load_buffer() with a MD routine that accepts a sglist. I will then reimplement the various bus dma front ends in MI code to generate (or accept) a sglist and then call the MD code.
Attack 4: read/write parallelism
Stuckee: jeffr
- f_offset serialization
- parallel reads, possibly with one or more writers.
(jeffr: Add details)