public inbox for linux-rt-users@vger.kernel.org
 help / color / mirror / Atom feed
From: John Kacur <jkacur@redhat.com>
To: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>,
	lkml <linux-kernel@vger.kernel.org>,
	rt-users <linux-rt-users@vger.kernel.org>,
	Clark Williams <williams@redhat.com>,
	Arnaldo Carvalho de Melo <acme@redhat.com>,
	Ingo Molnar <mingo@elte.hu>,
	Sven-Thorsten Dietrich <sven@thebigcorporation.com>,
	ghaskins@novell.com
Subject: Re: [PATCH 2/6: v4] lockdep: Make MAX_STACK_TRACE_ENTRIES configurable.
Date: Wed, 16 Jun 2010 22:37:33 +0200 (CEST)	[thread overview]
Message-ID: <alpine.LFD.2.00.1006162213220.28756@localhost.localdomain> (raw)
In-Reply-To: <1276714154.1745.623.camel@laptop>



On Wed, 16 Jun 2010, Peter Zijlstra wrote:

> On Tue, 2010-06-15 at 00:21 +0200, John Kacur wrote:
> > Certain debug configurations that have LOCKDEP turned on, run into the limit
> > where the MAX_STACK_TRACE_ENTRIES are too small. Rather than simply turning
> > off the locking correctness validator, let the user configure this value
> > to something reasonable for their system.
> > 
> > This patch was generated against 2.6.33.5-rt23 but is also intended to be
> > picked-up for mainline.
> 
> NACK
> 
> patches like 4726f2a617ebd868a4fdeb5679613b897e5f1676 are the way to go.

I've been testing 4726f2a617ebd868a4fdeb5679613b897e5f1676 in rt
(Thomas has it in tip/rt/2.6.33 now) and so far it is doing the trick for 
me, at least on my laptop. I still need to test it on larger machines.
However, this problem seems to continuably come up, and I'm not the only 
one who has expessed the wish / need to have this tunable.
See Message-Id	 <4BCEAD7B0200005A0006513E@soto.provo.novell.com>

and here in the same thread is even an argument that some configs
might tune it down. (I needed to increase it for rt-debug configs)
See Message-Id	 <1271861581.29617.13.camel@sven.thebigcorporation.com>

fwiw regarding a nacked patch, v4 is the least intrusive version
(smallest number of changes), based on a bit of trout wacking induced 
hints.  

Thanks

  reply	other threads:[~2010-06-16 20:38 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-06-14 22:21 [PATCH 0/6] Potential rt patches for tip/rt/2.6.33 John Kacur
2010-06-14 22:21 ` [PATCH 1/6] tracing: Update the comm field in the right variable in update_max_tr John Kacur
2010-06-14 22:21 ` [PATCH 2/6: v4] lockdep: Make MAX_STACK_TRACE_ENTRIES configurable John Kacur
2010-06-16 18:49   ` Peter Zijlstra
2010-06-16 20:37     ` John Kacur [this message]
2010-06-16 21:16       ` Peter Zijlstra
2010-06-16 21:29         ` Steven Rostedt
2010-06-17  8:35           ` Peter Zijlstra
2010-06-17  8:46             ` John Kacur
2010-06-18  3:56               ` Sven-Thorsten Dietrich
2010-06-16 21:33         ` John Kacur
2010-06-14 22:21 ` [PATCH 3/6] perf: Fix errors path in perf_output_begin() John Kacur
2010-06-14 22:21 ` [PATCH 4/6] KEYS: find_keyring_by_name() can gain access to a freed keyring John Kacur
2010-06-14 22:21 ` [PATCH 5/6] hvc_console: Fix race between hvc_close and hvc_remove John Kacur
2010-06-14 22:21 ` [PATCH 6/6] " John Kacur

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=alpine.LFD.2.00.1006162213220.28756@localhost.localdomain \
    --to=jkacur@redhat.com \
    --cc=acme@redhat.com \
    --cc=ghaskins@novell.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-rt-users@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=peterz@infradead.org \
    --cc=sven@thebigcorporation.com \
    --cc=tglx@linutronix.de \
    --cc=williams@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox