lkml.org 
[lkml]   [2006]   [Aug]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [ckrm-tech] [RFC][PATCH 2/7] UBC: core (structures, API)
    >>>>+	for (p = ub; p != NULL; p = p->parent) {
    >>>
    >>>
    >>>Seems rather expensive to walk up the tree for every charge. Especially
    >>>if the administrator wants a fine degree of resource control and makes a
    >>>tall tree. This would be a problem especially when it comes to resources
    >>>that require frequent and fast allocation.
    >>
    >>in heirarchical accounting you always have to update all the nodes :/
    >>with flat UBC this doesn't introduce significant overhead.
    >
    >
    > Except that you eventually have to lock ub0. Seems that the cache line
    > for that spinlock could bounce quite a bit in such a hot path.
    do you mean by ub0 host system ub which we call ub0
    or you mean a top ub?

    > Chandra, doesn't Resource Groups avoid walking more than 1 level up the
    > hierarchy in the "charge" paths?

    Kirill

    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2006-08-21 13:03    [W:5.238 / U:0.016 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site