Re: [Lse-tech] Re: [ckrm-tech] Re: [PATCH 00/01] Move Exit Connectors

[Shailabh Nagar]

Jes Sorensen wrote:
>>>>>>"Matt" == Matt Helsley <matthltc@xxxxxxxxxx> 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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/