lkml.org 
[lkml]   [2012]   [Dec]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH 09/19] list_lru: per-node list infrastructure
    On 11/28/2012 03:14 AM, Dave Chinner wrote:
    > From: Dave Chinner <dchinner@redhat.com>
    >
    > Now that we have an LRU list API, we can start to enhance the
    > implementation. This splits the single LRU list into per-node lists
    > and locks to enhance scalability. Items are placed on lists
    > according to the node the memory belongs to. To make scanning the
    > lists efficient, also track whether the per-node lists have entries
    > in them in a active nodemask.
    >

    I think it is safe to assume that these functions could benefit from
    having more metadata available for them when they run.

    Let's say for instance that a hypothetical person, for some unknown
    reasons, comes with the idea of replicating those lists transparently
    per memcg.

    In this case, it is very useful to know which memcg drives the current
    call. In general, the struct shrink_control already contains a lot of
    data that we use to drive the process. Wouldn't it make sense to also
    pass shrink_control as data to those lists as well?

    The only drawback of this, is that it would tie it to the shrinking
    process. I am not sure if this is a concern, but it if is, maybe we
    could replace things like :

    +static long
    +list_lru_walk_node(
    + struct list_lru *lru,
    + int nid,
    + list_lru_walk_cb isolate,
    + void *cb_arg,
    + long *nr_to_walk)
    +{

    with

    +static long
    +list_lru_walk_node(
    + struct list_lru *lru,
    + struct something_like_shrink_control_not_shrink_control *a)
    +{

    This way we can augment the data available for the interface, for
    instance, passing the memcg context, without going patching all the callers.



    \
     
     \ /
      Last update: 2012-12-20 13:01    [W:4.402 / U:0.152 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site