Re: [PATCH] Optimize struct task_delay_info

["Zhang, Yanmin" <yanmin_zhang@linux.intel.com>]

On Thu, 2007-07-12 at 14:21 -0400, Frank Ch. Eigler wrote:
> "Zhang, Yanmin" <yanmin_zhang@linux.intel.com> writes:
> 
> > [...]
> > > > 2) Delete lock. [..]
> > > > In addition, the result is for performance data collection, so it's
> > > > unnecessary to add such lock.
> > > Not sure that's a good idea. People expect their performance counts
> > > to be accurate too. [...]
> > [...]
> > 2) If the reader could get the correct data when the process updates
> > the data. It might be an issue. But the issue is not
> > important. Mostly, the application tool reads the data in an
> > interval.
> 
> Can you elaborate on that some more? 
If there is no the lock, the blkio_delay/swapin_delay might have the latest
value but the count is 1 less than the correct value.

> Is it OK for the sample
> monitoring program to return inconsistent data sometimes?
That needs Shailabh Nagar's comments.

What I tried to say is the inconsistent issue is not severe and happened rarely.
The mostly-used scenario is a performance tool reads the data per time-slot in
a loop, so I think it wouldn't hurt the usage model.

>   Is there
> reason to believe that this sample user-space program will remain the
> sole consumer of this data?  Might a seqlock be appropriate here?
seqlock is helpful, but my start point is to save memory space without hurt to application.
As you know, every process (thread) has its own struct task_delay_info.

Yanmin