lkml.org 
[lkml]   [2006]   [Jan]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [Lse-tech] Re: [ckrm-tech] Re: [PATCH 00/01] Move Exit Connectors
    Jes Sorensen wrote:
    >>>>>>"Matt" == Matt Helsley <matthltc@us.ibm.com> writes:
    >
    >
    > Matt> Right. I forgot to repeat what I mentioned in the parent email
    > Matt> -- that this patch is intended to be applied on top of
    > Matt> Shailabh's patches.
    >
    > Matt> The first patch I posted (01/01) is intended for plain
    > Matt> 2.6.15. Before proposing 01/01 for -mm I've been trying to see
    > Matt> if there are any problems with the value of tsk->exit_signal
    > Matt> before exit_mm() -- hence the "[RFC]" in the subject line of
    > Matt> that one.
    >
    > Matt,
    >
    > Any chance one of you could put up a set of current patches somewhere?

    I'll upload the delay accounting patches to a newly created lse-tech package.

    > I am trying to make heads and tails of them and it's pretty hard as I
    > haven't been on lse-tech for long and the lse-tech mailing list
    > archives are useless due to the 99 to 1 SPAM ratio ;-(
    >


    > I am quite concerned about that lock your patches put into struct
    > task_struct through struct task_delay_info. Have you done any
    > measurements on how this impacts performance on highly threaded apps
    > on larger system?

    I don't expect the lock contention to be high. The lock is held for a
    very short time (across two additions/increments). Moreover, it gets
    contended only when the stats are being read (either through /proc or connectors).
    Since the reading of stats won't be that frequent (the utility of these
    numbers is to influence the I/O priority/rss limit etc. which won't be done
    at a very small granularity anyway), I wouldn't expect a problem.

    But its better to take some measurements anyway. Any suggestions on a
    benchmark ?

    > IMHO it seems to make more sense to use something like Jack's proposed
    > task_notifier code to lock-less collect the data into task local data
    > structures and then take the data from there and ship off to userland
    > through netlink or similar like you are doing?
    >
    > I am working on modifying Jack's patch to carry task local data and
    > use it for not just accounting but other areas that need optional
    > callbacks (optional in the sense that it's a feature that can be
    > enabled or disabled). Looking at Shailabh's delayacct_blkio() changes
    > it seems that it would be really easy to fit those into that
    > framework.
    >
    > Guess I should post some of this code .....

    Please do. If this accounting can fit into some other framework, thats fine too.

    -- Shailabh

    > Cheers,
    > Jes
    >

    -
    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-01-06 17:47    [W:5.481 / U:0.024 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site