Buf cache renovation project

As decided by the junta at BSDcan2008

Attack 1: VREG data from buf to VM

Stuckee: jeffr

(jeffr: add details)

Attack 2: Syncer to per-{bufobj,mount} threads

Stuckee: ? (phk ?)

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

(jeffr: Add details)


CategoryInactiveProject

Buf0x (last edited 2018-07-21T04:10:20+0000 by MarkLinimon)