lkml.org 
[lkml]   [2013]   [Jan]   [18]   [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 01/18/2013 04:10 PM, Dave Chinner wrote:
    > On Fri, Jan 18, 2013 at 11:10:00AM -0800, Glauber Costa wrote:
    >> On 01/18/2013 12:11 AM, Dave Chinner wrote:
    >>> On Thu, Jan 17, 2013 at 04:14:10PM -0800, Glauber Costa wrote:
    >>>> On 01/17/2013 04:10 PM, Dave Chinner wrote:
    >>>>> And then each object uses:
    >>>>>
    >>>>> struct lru_item {
    >>>>> struct list_head global_list;
    >>>>> struct list_head memcg_list;
    >>>>> }
    >>>> by objects you mean dentries, inodes, and the such, right?
    >>>
    >>> Yup.
    >>>
    >>>> Would it be acceptable to you?
    >>>
    >>> If it works the way I think it should, then yes.
    >>>
    >>>> We've been of course doing our best to avoid increasing the size of the
    >>>> objects, therefore this is something we've never mentioned. However, if
    >>>> it would be acceptable from the fs POV, this would undoubtedly make our
    >>>> life extremely easier.
    >>>
    >>> I've been trying hard to work out how to avoid increasing the size
    >>> of structures as well. But if we can't work out how to implement
    >>> something sanely with only a single list head per object to work
    >>> from, then increasing the size of objects is something that we need
    >>> to consider if it solves all the problems we are trying to solve.
    >>>
    >>> i.e. if adding a second list head makes the code dumb, simple,
    >>> obviously correct and hard to break then IMO it's a no-brainer.
    >>> But we have to tick all the right boxes first...
    >>>
    >>
    >> One of our main efforts recently has been trying to reduce memcg impact
    >> when it is not in use, even if its compiled in. So what really bothers
    >> me here is the fact that we are increasing the size of dentries and
    >> inodes no matter what.
    >>
    >> Still within the idea of exploring the playing field, would an
    >> indirection be worth it ?
    >> We would increase the total per-object memory usage by 8 bytes instead
    >> of 16: the dentry gets a pointer, and a separate allocation for the
    >> list_lru.
    >
    > A separate allocation is really not an option. We can't do an
    > allocation in where dentries/inodes/other objects are added to the
    > LRU because they are under object state spinlocks, and adding a
    > potential memory allocation failure to the "add to lru" case is
    > pretty nasty, IMO.
    >

    That would of course happen on dentry creation time, not lru add time.
    It is totally possible since at creation time, we already know if memcg
    is enabled or not.


    \
     
     \ /
      Last update: 2013-01-19 02:01    [W:2.503 / U:0.408 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site