[ For RCU trace which is not yet in mainline ]
In the initialization of the RCU trace module, if
rcupreempt_debugfs_init() fails, we never free the the trace buffer.
This patch frees the trace buffer in case the debugfs fails.
Signed-off-by: Steven Rostedt [EMAIL PROTECTED]
Index:
Hi
I'm porting an application from another realtime-os to Linux. This
application makes use of intLock() from time to time. I still need the the
application to be compilable on both Linux and my old os, so I need a
portabel intLock()
I have tried the following approach:
When a thread needs to do
We are pleased to announce the 2.6.23-rc9-rt2 tree, which can be
downloaded from the new location:
http://www.kernel.org/pub/linux/kernel/projects/rt/
Changes since 2.6.23-rc9-rt1
- x86_64 disable IST for debug (Andi Kleen)
- Better handling of dynticks going bad in RCU (Steven Rostedt)
On Wed, Oct 03, 2007 at 04:59:51PM -0400, Steven Rostedt wrote:
Paul,
I ran your original preemption test of RCU torture, and after several
minutes, my preempt boost patch had one Preemption stall. I then
disabled preemption boosting, and ran the preempt torture again, and it
seemed to
Doh! I guess there should be a rule about sending patches out after midnight
;)
The original patch I worked on was written before the code was moved to
validate_chain(), so my previous posting didnt quite translate when I merged
with git HEAD. Here is an updated patch. Sorry for the confusion.
Hi Ingo,
I am seeing a problem on the latest -rt where lockdep completely overwhelms
the system to the point that it grinds to a halt on large (8-way+) systems.
The problem seems to be that the class-locks_before and locks_after grow
unbounded (I have observed over 1M+ entries in them) so
