Re: [Patch 0/9] Per-task delay accounting

[Shailabh Nagar <nagar@watson.ibm.com>]

Greg KH wrote:

> On Tue, Mar 14, 2006 at 03:49:16PM -0500, Shailabh Nagar wrote:
>  
>
> > Greg KH wrote:
> >
> >    
> >
> > > On Mon, Mar 13, 2006 at 07:40:34PM -0500, Shailabh Nagar wrote:
> > >
> > >
> > >      
> > >
> > > > This is the next iteration of the delay accounting patches
> > > > last posted at
> > > > 	http://www.ussg.iu.edu/hypermail/linux/kernel/0602.3/0893.html
> > > >  
> > > >
> > > >        
> > > Do you have any benchmark numbers with this patch applied and with it
> > > not applied? 
> > >
> > >      
> > None yet. Wanted to iron out the collection/utility aspects a bit before 
> > going into
> > the performance impact.
> >
> > But this seems as good a time as any to collect some stats
> > using the usual suspects lmbench, kernbench, hackbench etc.
> >
> >    
> >
> > > Last I heard it was a measurable decrease for some
> > > "important" benchmark results...
> > >
> > >
> > >      
> > Might have been from an older iteration where schedstats was fully enabled.
> > But no point speculating....will run with this set of patches and see 
> > what shakes out.
> >
> > One point about the overhead is that it depends on the frequency with 
> > which data is
> > collected. So a proper test would probably be a comparison of a 
> > non-patched kernel
> > with
> > a) patches applied but delay accounting not turned on at boot i.e. cost 
> > of the checks
> > b) delay accounting turned on but not being read
> >    
>
> This is probably the most important one, as that is what distros will be
> looking at.  They will have to enable the option, but will not "turn it
> on".
>  
I guess you meant a), not b) but yes, will run them in all these modes.

>  
>
> > c) delay accounting turned on and data read for all tasks at some 
> > "reasonable" rate
> >
> > Will that be good  ? Other suggestions welcome.
> >    
>
> How about real benchmarks?  The ones that the big companies look at?  I
> know you have access to them :)
>  
Hmm...though you also know, from working for some "big company",  that 
it might
take a while to get such data since one has to stand in queue :-)
I'll try, and also explore the OSDL STP's DBT tests.


Thanks,
Shailabh

> thanks,
>
> greg k-h
>  

-
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/