From: Sven-Thorsten Dietrich <sdietrich@novell.com>
To: John Kacur <jkacur@redhat.com>, mgalbraith@suse.de
Cc: Peter Zijlstra <peterz@infradead.org>,
rostedt@goodmis.org, 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>,
ghaskins@novell.com
Subject: Re: [PATCH 2/6: v4] lockdep: Make MAX_STACK_TRACE_ENTRIES configurable.
Date: Thu, 17 Jun 2010 20:56:11 -0700 [thread overview]
Message-ID: <1276833371.16751.9.camel@sven.thebigcorporation.com> (raw)
In-Reply-To: <alpine.LFD.2.00.1006171039050.22185@localhost.localdomain>
On Thu, 2010-06-17 at 10:46 +0200, John Kacur wrote:
> Also as I pointed out, in Sven's case it sounds like they may
> have had a build where they even wanted to decrease it.
>
I hacked the patch below for SLERT 10 a few years ago, and that's
shipping still.
As you can see from the comment in the patch header, I was aware that
this wasn't a closed case, but rather a stop-gap.
I think if I had spent any more time on it, or run into the issue
repeatedly, my first instinct would have been to do what John did, i.e.
make it configurable.
However, I think that fundamentally, if nesting goes that deep, simply
increasing this define would lead to masking real problems.
So while I hacked this up for a shipping product, with intention to
debug this later, I'd probably favor a proper fix of the offending call
chain upstream.
I do not recall ever trying to decrease it, other than to reproduce the
issue a few times. I never did have time to dig into it further, and we
closed the bug as won't fix for this particular product.
Regards,
Sven
Subject: Increase lockdep's MAX_STACK_TRACE_ENTRIES
From: Sven-Thorsten Dietrich <sdietrich@suse.de>
For large SMP systems, MAX_STACK_TRACE_ENTRIES was too low, and
lockdep would complain. This change addresses the issue on systems
we have tested.
It remains to be determined whether other bugs (e.g. scheduler
balancing issues led to unreasonably deep call chains)
Signed-off-by: Sven-Thorsten Dietrich <sdietrich@suse.de>
Index: linux-2.6.22/kernel/lockdep_internals.h
===================================================================
--- linux-2.6.22.orig/kernel/lockdep_internals.h
+++ linux-2.6.22/kernel/lockdep_internals.h
@@ -27,7 +27,7 @@
* Stack-trace: tightly packed array of stack backtrace
* addresses. Protected by the hash_lock.
*/
-#define MAX_STACK_TRACE_ENTRIES 262144UL
+#define MAX_STACK_TRACE_ENTRIES 524288UL
extern struct list_head all_lock_classes;
next prev parent reply other threads:[~2010-06-18 3:56 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
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 [this message]
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=1276833371.16751.9.camel@sven.thebigcorporation.com \
--to=sdietrich@novell.com \
--cc=acme@redhat.com \
--cc=ghaskins@novell.com \
--cc=jkacur@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-rt-users@vger.kernel.org \
--cc=mgalbraith@suse.de \
--cc=mingo@elte.hu \
--cc=peterz@infradead.org \
--cc=rostedt@goodmis.org \
--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;
as well as URLs for NNTP newsgroup(s).