Re: [Patch 1/4] Delay accounting: Initialization

[Parag Warudkar <kernel-stuff@comcast.net>]

On Nov 15, 2005, at 5:29 PM, Shailabh Nagar wrote:
>>
>> Curious as to when would this occur. Probably for tasks running on a
>> SMP machine for a very short period of time (timer drift should  
>> not  be
>> hopefully that high) and switching CPUs in that short period of time?
>
> Possibly. Also, the simpler case of wraparound needs to be handled.  
> Since
> one delay sample isn't significant, dropping it seemed the safest bet.
>
Yep, better to report zero than invalid values.

>
>>> +config STATS_CONNECTOR
>>> +config DELAY_ACCT
>>
>>
>> Probably TASK_DELAY_STATS_CONNECTOR and TASK_DELAY_ACCOUNTING are
>> better names?
>
> TASK_DELAY_ACCOUNTING is better since thats what the code protected
> does.
>
> STATS_CONNECTOR can be used to transmit stats other than per-task
> delays (current patch also transmits cpu run time). Also there's a  
> possibility
> that the overall per-task accounting solution whose discussion was  
> proposed
> by Andrew will deviate from delays. So how about TASK_STATS_CONNECTOR.
>>

Sounds good.

>> Does this mean, whether or not the per task delay accounting is used,
>> we have a constant overhead of sizeof(spinlock_t) + 2*sizeof  
>> (uint32_t)
>> + 2* sizeof(uint64_t) bytes going into the struct  task_struct?.  
>> Is it
>> possible/beneficial to use struct task_delay_info  *delays instead  
>> and
>> allocate it if task wants to use the information?
>>
>
> Doing so would have value in the case where the feature is  
> configured but
> no one ever registers to listen for it.

Precisely. Such a feature will be used only occasionally I suppose.
I didn't read the code deeply but are any scheduling decisions  
altered based on
this data? If not, then it makes sense to not account unless required.

I think it should be possible to do it on demand, per process instead  
of forcing
the accounting on _all_ processes which cumulatively becomes a  
sizeable o/h.

Per Process activation of this feature will add significant value  
IMHO. (Of course,
if that's possible in first place.)

> The cost of doing this would be
> - adding more code to the fork path to allocate conditionally

Just an unlikely branch for normal code path - not a big deal.
Also I am thinking it could be handled outside of fork?

> - make the collecting of the delays conditional on a similar check

Weighing this against the actual accounting - I think it's a win.

> - cache pollution from following an extra pointer in the pgflt/ 
> io_schedule paths
> I'm not sure is this really matters for these two code paths.

Possibly.

> Even if one does this, once the first listener registers, all  
> future tasks
> (and even the current ones) will have to go ahead and allocate the  
> structure
> and accounting of delays will have to switch to unconditional mode.  
> This is
> because the delay data has cumulative value...future listeners will be
> interested in data collected earlier (as long as task is still  
> running). And
> once the first listener registers, you can no longer be sure no  
> one's interested
> in the future.
>

Is it possible to do it per process? Forcing it on all processes is  
what I was trying
to avoid given the feature's usage pattern.

> Another alternative is to let userland control the overhead of  
> allocation and
> collection completely through a /proc/sys/kernel/delayacct variable.
> When its switched on, it triggers an allocation for all existing  
> tasks in the
> system, turns on allocation in fork() for future tasks, and  
> collection of the stats.
> When turned off, collection of stats stops as does allocation for  
> future tasks
> (not worth going in and deallocating structs for existing tasks).

> Does this seem worth it ?
>

Definitely not unless we can do it per process and on demand.

> -- Shailabh
>

Cheers

Parag