[lkml]   [2006]   [Feb]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH 1/5] cpuset memory spread basic implementation
    > >  I'd have thought it would be saner to split these things apart:
    > > "slab_spread", "pagecache_spread", etc.
    > This, please. It impacts the design of the whole thing.

    It was still in my queue to respond to, yes.

    All I am aware that is needed is to distinguish between:

    (1) application space pages, such as data and stack space,
    which the applications can page and place under their
    detailed control, and

    (2) what from the application's viewpoint is "kernel stuff"
    such as large amounts of pages required by file i/o,
    and their associated inode/dentry structures.

    The application space pages are typically anonymous pages
    which go away when the owning tasks exits, while the kernel
    space pages are typically accessible by multiple tasks and
    can stay around long after the initial faulting task exits.

    I prefer to keep the tunable knobs to a minimum. One boolean
    was sufficient for this.

    Just because a distinction seems substantial from the kernel
    internals perspective, doesn't mean we should reflect that in
    the tunable knobs. We should have an actual need first, not
    a strawman.

    If there is some reason, or preference, for adding two knobs
    (slab and page) instead of one, I can certainly do it.

    I am not yet aware that such is useful.

    I won't rest till it's the best ...
    Programmer, Linux Scalability
    Paul Jackson <> 1.925.600.0401
    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: 2006-02-06 06:53    [W:0.019 / U:4.380 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site