Buf cache renovation project

As decided by the junta at BSDcan2008

Stuckee: jeffr

• Move the regular file data out of the buffercache, let VM system manage it.

(jeffr: add details)

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)

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.

Stuckee: jeffr

• f_offset serialization
• parallel reads, possibly with one or more writers.

(jeffr: Add details)