AF:
NF:0
PS:10
SRH:1
SFN:
DSR:
MID:
CFG:
PT:0
S:andy.sharp@lsi.com
RQ:
SSV:mhbs.lsil.com
NSV:
SSH:
R:<Maxim.Kozlovsky@lsi.com>
MAID:2
X-Sylpheed-Privacy-System:
X-Sylpheed-Sign:0
SCF:#mh/Mailbox/sent
RMID:#imap/LSI/INBOX	0	861DA0537719934884B3D30A2666FECC010E06B458@cosmail02.lsi.com
X-Sylpheed-End-Special-Headers: 1
Date: Thu, 4 Feb 2010 15:25:09 -0800
From: Andrew Sharp <andy.sharp@lsi.com>
To: "Kozlovsky, Maxim" <Maxim.Kozlovsky@lsi.com>
Subject: Re: Please review  .8
Message-ID: <20100204152509.3ea928ec@ripper.onstor.net>
In-Reply-To: <861DA0537719934884B3D30A2666FECC010E06B458@cosmail02.lsi.com>
References: <861DA0537719934884B3D30A2666FECC010E06B3F7@cosmail02.lsi.com>
	<20100204134625.20308c8a@ripper.onstor.net>
	<861DA0537719934884B3D30A2666FECC010E06B427@cosmail02.lsi.com>
	<20100204140036.29adab78@ripper.onstor.net>
	<861DA0537719934884B3D30A2666FECC010E06B448@cosmail02.lsi.com>
	<20100204141340.15b0564c@ripper.onstor.net>
	<861DA0537719934884B3D30A2666FECC010E06B458@cosmail02.lsi.com>
Organization: LSI
X-Mailer: Sylpheed-Claws 2.6.0 (GTK+ 2.8.20; x86_64-pc-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

On Thu, 4 Feb 2010 15:22:32 -0700 "Kozlovsky, Maxim"
<Maxim.Kozlovsky@lsi.com> wrote:

> 
> 
> -----Original Message-----
> From: Andrew Sharp [mailto:andy.sharp@lsi.com] 
> Sent: Thursday, February 04, 2010 2:14 PM
> To: Kozlovsky, Maxim
> Subject: Re: Please review .8
> 
> On Thu, 4 Feb 2010 15:07:49 -0700 "Kozlovsky, Maxim"
> <Maxim.Kozlovsky@lsi.com> wrote:
> 
> > >      i believe this code is redundant -- there is generic kernel
> > > code for doing this on the sb1 processors.  we will not only want
> > > to use that, but use a generic api on top of it if it doesn't
> > > already, for when we go to x86
> > > [MK] what is this code? I have not found any references to
> > > ZBBUS_CYCLE_COUNT anywhere in the kernel code. 
> > 
> > Start with the file arch/mips/sibyte/Kconfig and look for
> > 
> > SIBYTE_HAS_ZBUS_PROFILING
> > SIBYTE_TBPROF
> > SIBYTE_BW_TRACE
> > 
> > and other similar config variables and follow them to the code they
> > controll.  And let me know what you find, since I've never looked
> > all that closely at it.  If you want to punt it for now, that's
> > fine too. Might be a good project for one of those guys up in
> > Beaverton. [MK] 
> > That is different, this is the profiler using the various
> > performance counters. This is typical statistical profiling done
> > using interrupts which does not need precise timer source. We had
> > that ported to EEE on bobcat. KPIs measure the exact time something
> > takes and rely on very high precision timer register with very fast
> > access - single instruction or so. X86 will definitely have
> > something similar.
> 
> SIBYTE_TBPROF is using the zbus, same as our stuff, no?
> 
> 
> [MK] Not really. This thing uses the zbus performance counter
> registers. A register is armed by writing some value in there and the
> register counts down to 0 whenever some event happens (dcache miss,
> icache miss, bus clock tick, etc). There is a register per each type
> of event. Register hitting 0 causes an interrupt, the profiler
> handles the interrupt by registering the PC where the interrupt
> happened and writes it to the log. If we were to use just bus clock
> ticks, we will end up with exactly what gprof does. KPIs measure the
> time various stages of request execution take by taking the exact
> time the stage starts and ends.  

OK, I didn't realize we were talking about KPIs, I thought this was
just about profiling.


> > > linux/kernel/linux-mips-2.6/net/neteee2/eee-timer.c
> > > 
> > >      looks good
> > > 
> > > linux/kernel/linux-mips-2.6/net/tpl/tpl-ipc.c
> > > 
> > >      looks good
> > > 
> > > nfx-tree/code/neteee2/eee-timer-api.h
> > > 
> > >      this file is dead.  i think.  better safe then sorry i guess.
> > > [MK] Not until Bill checks in his changes, and who knows how long
> > > that is going to take.
> > 
> > Right.  That's why I said "better safe than sorry".
