From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gdb-patches-return-96334-listarch-gdb-patches=sources.redhat.com@sourceware.org>
Received: (qmail 27255 invoked by alias); 27 Nov 2012 18:56:29 -0000
Received: (qmail 27244 invoked by uid 22791); 27 Nov 2012 18:56:28 -0000
X-SWARE-Spam-Status: No, hits=-4.9 required=5.0	tests=BAYES_00,DKIM_ADSP_CUSTOM_MED,DKIM_SIGNED,DKIM_VALID,FREEMAIL_FROM,KHOP_RCVD_TRUST,KHOP_THREADED,NML_ADSP_CUSTOM_MED,RCVD_IN_DNSWL_LOW,RCVD_IN_HOSTKARMA_YE
X-Spam-Check-By: sourceware.org
Received: from mail-ea0-f169.google.com (HELO mail-ea0-f169.google.com) (209.85.215.169)    by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 27 Nov 2012 18:56:22 +0000
Received: by mail-ea0-f169.google.com with SMTP id a12so4983143eaa.0        for <gdb-patches@sourceware.org>; Tue, 27 Nov 2012 10:56:21 -0800 (PST)
Received: by 10.14.178.7 with SMTP id e7mr45111700eem.44.1354042581298;        Tue, 27 Nov 2012 10:56:21 -0800 (PST)
Received: from [192.168.0.10] (HSI-KBW-078-043-072-214.hsi4.kabel-badenwuerttemberg.de. [78.43.72.214])        by mx.google.com with ESMTPS id f49sm11568895eep.12.2012.11.27.10.56.12        (version=TLSv1/SSLv3 cipher=OTHER);        Tue, 27 Nov 2012 10:56:20 -0800 (PST)
Subject: Re: [patch v4 00/13] branch tracing support for Atom
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
Content-Type: text/plain; charset=us-ascii
From: Markus Metzger <markus.t.metzger@googlemail.com>
In-Reply-To: <20121127175955.GA8901@host2.jankratochvil.net>
Date: Tue, 27 Nov 2012 18:56:00 -0000
Cc: "Metzger, Markus T" <markus.t.metzger@intel.com>, "gdb-patches@sourceware.org" <gdb-patches@sourceware.org>, "palves@redhat.com" <palves@redhat.com>, "tromey@redhat.com" <tromey@redhat.com>, "kettenis@gnu.org" <kettenis@gnu.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <11AC197E-8662-45CB-9D99-355786849BD8@gmail.com>
References: <1354013351-14791-1-git-send-email-markus.t.metzger@intel.com> <20121127131055.GB22431@host2.jankratochvil.net> <A78C989F6D9628469189715575E55B2307B28995@IRSMSX102.ger.corp.intel.com> <20121127143235.GA31270@host2.jankratochvil.net> <20121127153603.GA1899@host2.jankratochvil.net> <A78C989F6D9628469189715575E55B2307B29168@IRSMSX102.ger.corp.intel.com> <20121127162740.GA4512@host2.jankratochvil.net> <A78C989F6D9628469189715575E55B2307B29292@IRSMSX102.ger.corp.intel.com> <20121127175955.GA8901@host2.jankratochvil.net>
To: Jan Kratochvil <jan.kratochvil@redhat.com>
Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <gdb-patches.sourceware.org>
List-Subscribe: <mailto:gdb-patches-subscribe@sourceware.org>
List-Archive: <http://sourceware.org/ml/gdb-patches/>
List-Post: <mailto:gdb-patches@sourceware.org>
List-Help: <mailto:gdb-patches-help@sourceware.org>, <http://sourceware.org/ml/#faqs>
Sender: gdb-patches-owner@sourceware.org
X-SW-Source: 2012-11/txt/msg00772.txt.bz2


On Nov 27, 2012, at 6:59 PM, Jan Kratochvil <jan.kratochvil@redhat.com> wro=
te:

> On Tue, 27 Nov 2012 18:30:03 +0100, Metzger, Markus T wrote:
>> Btrace uses a ring buffer into which the h/w writes from-to records for =
each
>> branch. We will only see the tail of the execution trace.
>=20
> OK, I see only 168 entries here.  Originally I expected kernel traps and
> records the buffer each time.  arch/x86/ even sets bts_interrupt_threshol=
d,
> why is the recorded buffer so short?
>=20
> With such short recorded buffer I understand the backtracing feature is n=
ot
> much useful.  Although I do not understand why only so few entries got
> recorded.

I hard-coded one page of trace (or, rather, perf_event) buffer per thread. =
We could make this configurable. I have not done this, yet, since I wanted =
to keep the patch series small and simple until I get feedback.

regards,
markus.