[lkml]   [2003]   [Jun]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [RFC] My research agenda for 2.7
    On Sat, 28 Jun 2003, Daniel Phillips wrote:

    > There's no question that that's the case today. However, there are good
    > reasons for using a largish filesystem blocksize, 16K for example, once it
    > becomes possible to do so.

    Fair enough. I am not very familiar with filesystems or why it would be
    desirable to have a blocksize greater than a page size. I'd be grateful if
    you'd recommend a good book, paper or documentation set that would
    enlighten me.

    > > Because they are so common in comparison to other orders, I
    > > think that putting order0 in slabs of size 2^MAX_ORDER will make
    > > defragmentation *so* much easier, if not plain simple, because you can
    > > shuffle around order0 pages in the slabs to free up one slab which frees
    > > up one large 2^MAX_ORDER adjacent block of pages.
    > But how will you shuffle those pages around?

    Thats where your defragger would need to kick in. The defragger would scan
    at most MAX_DEFRAG_SCAN slabs belonging to the order0 userspace cache
    where MAX_DEFRAG_SCAN is related to how urgent the request is. Select the
    slab with the least objects in them and either:

    a) Reclaim the pages by swapping them out or whatever
    b) Copy the pages to another slab and update the page tables via rmap

    Once the pages are copied from the selected slab, destroy it and you have
    a large block of free pages. The point which I am getting across, quite
    badly, is that by having order0 pages in slab, you are guarenteed to be
    able to quickly find a cluster of pages to move which will free up a
    contiguous block of 2^MAX_ORDER pages, or at least 2^MAX_GFP_ORDER with
    the current slab implementation.

    For kernel pages, it would get a lot more complicated but at least the
    kernel pages would be clustered together in the order0 cache for kernel

    Mel Gorman
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 13:46    [W:0.021 / U:7.272 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site