[Lse-tech] Re: [Patch 2/8] Sync block I/O and swapin delay collection

[Balbir S. <ba...@in...>]

On Tue, May 09, 2006 at 06:20:12PM +1000, Nick Piggin wrote:
> Balbir Singh wrote:
> 
> >On Tue, May 09, 2006 at 03:57:06PM +1000, Nick Piggin wrote:
> >
> >>Well they'll be _collecting_ the stats, yes. Will they really be using
> >>them for anything?
> >>
> >
> >Hmm.. No, the statistics are sent down using the netlink interface
> >to listeners on the netlink group (on every task exit) or to the task that
> >actually requested for the delay accounting data.
> >
> >The stats are currently gathered in kernel and used by user space.
> >
> 
> So... what are the consumers of this data going to be? That is my question.

More details on the consumers of this data is available at
http://lkml.org/lkml/2006/3/13/367

> 
> >>If you make the whole thing much lighter weight for tasks which aren't
> >>using the accounting, you have a better chance of people turning the
> >>CONFIG option on.
> >>
> >>
> >
> >I am not sure I understand the point completely. Are you suggesting that
> >struct task_delay_info be moved to common data structure as an aggregate
> >containing all the delay stats data?
> >
> 
> My suggestion is basically this: if the accounting is going to be used
> infrequently, it might be a good idea to allocate the accounting structures
> on demand, and only perform the accounting when these structures are
> allocated.
> 
> It all adds up. Extra cache misses, more icache, more logic, etc... I 
> suspect
> that relatively few people will care about these stats.
>

Thanks for clarifying.  I now understand your suggestion better.

The accounting is going to be frequent, with data from all tasks in the
system being collected and processed frequently. Since the accounting is
frequent, I think the current scheme works better than on-demand allocation.

Regarding the usefulness of these stats, please see
http://www.uwsg.iu.edu/hypermail/linux/kernel/0604.2/1731.html


	Balbir Singh,
	Linux Technology Center,
	IBM Software Labs