From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 68A5D3B2A0 for ; Mon, 21 Nov 2016 11:24:23 -0500 (EST) Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 75CAF804E4; Mon, 21 Nov 2016 16:24:22 +0000 (UTC) Received: from localhost (ovpn-200-33.brq.redhat.com [10.40.200.33]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id uALGOKdR011418; Mon, 21 Nov 2016 11:24:20 -0500 Date: Mon, 21 Nov 2016 17:24:18 +0100 From: Jesper Dangaard Brouer To: Dave Taht Cc: make-wifi-fast@lists.bufferbloat.net, brouer@redhat.com Message-ID: <20161121172418.04d17aad@redhat.com> In-Reply-To: References: <20161118085524.62d6cfdd@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.27 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.27]); Mon, 21 Nov 2016 16:24:22 +0000 (UTC) Subject: Re: [Make-wifi-fast] a bit of profiling on the archer X-BeenThere: make-wifi-fast@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Nov 2016 16:24:23 -0000 On Sat, 19 Nov 2016 10:30:10 -0800 Dave Taht wrote: > Jesper/eric: > > If you have any satisfying network oneliners and stats to monitor via > perf along the lines of > > http://www.brendangregg.com/perf.html#OneLiners > > it would be helpful longer term. Good point... I'll think where we can easily publish such oneliners. > The mips platforms have sprouted more events than it ever had before > (well, until last year, perf didn't work at all): > > Of these besides the cpu-cycles thing, the only stuff I've looked at > are various wake_tx_queue related events, and I have a scar involved > in unaligned_accesses (but we're not doing any, soo) > > branch-instructions OR branches [Hardware event] > branch-misses [Hardware event] > cpu-cycles OR cycles [Hardware event] > instructions [Hardware event] I'm very happy to see this is HW events in this platform! :-) Guess, I should buy one of these ;-) This is the Archer? which is what kind of CPU? > alignment-faults [Software event] > bpf-output [Software event] > context-switches OR cs [Software event] > cpu-clock [Software event] > cpu-migrations OR migrations [Software event] > dummy [Software event] > emulation-faults [Software event] > major-faults [Software event] > minor-faults [Software event] > page-faults OR faults [Software event] > task-clock [Software event] > L1-dcache-load-misses [Hardware cache event] > L1-dcache-loads [Hardware cache event] > L1-dcache-store-misses [Hardware cache event] > L1-dcache-stores [Hardware cache event] > L1-icache-load-misses [Hardware cache event] > L1-icache-loads [Hardware cache event] > L1-icache-prefetches [Hardware cache event] The icache HW events are actually quite interesting. And three of them, on my Intel Skylake CPU I only have "L1-icache-load-misses". > LLC-load-misses [Hardware cache event] > LLC-loads [Hardware cache event] > LLC-store-misses [Hardware cache event] > LLC-stores [Hardware cache event] LLC = Last Level Cache. Do you have any info on what the cache layout and sizes of this CPU is? LLC indicate it might have a L2 cache? > branch-load-misses [Hardware cache event] > branch-loads [Hardware cache event] > iTLB-load-misses [Hardware cache event] > iTLB-loads [Hardware cache event] > rNNN [Raw hardware event descriptor] > cpu/t1=v1[,t2=v2,t3 ...]/modifier [Raw hardware event descriptor] > mem:[/len][:access] [Hardware breakpoint] > ath10k:ath10k_htt_pktlog [Tracepoint event] > ath10k:ath10k_htt_rx_desc [Tracepoint event] You can use tracepoints if you want to find/analyse very specific issue, but not so useful for general perf monitoring. -- Best regards, Jesper Dangaard Brouer MSc.CS, Principal Kernel Engineer at Red Hat Author of http://www.iptv-analyzer.org LinkedIn: http://www.linkedin.com/in/brouer