Re: Realtime Preemption, 2.6.12, Beginners Guide?

[Ingo Molnar <mingo@elte.hu>]

* Alistair John Strachan <s0348365@sms.ed.ac.uk> wrote:

> Well, just to let others who have this problem know, it's clear that 
> Ingo's rt-preempt patches increase stack pressure on systems (like 
> mine) where stack is borderline under 4K by default.
> 
> If you disable CONFIG_4KSTACKS the stack overflows seem to disappear.  
> As a result, until we isolate the problem, it'd probably be better if 
> Ingo maintained an 8K stacks option in the rt-preempt patches assuming 
> Adrian Bunk's "kill !4KSTACKS" patch gets into mainline..

Ok. Could you try to debug this some more? In the -51-17 patch i've 
implemented a new stack-overflow debugging feature: 'stack footprint 
maximum searching'. It is automatically active if you have 
CONFIG_LATENCY_TRACE and CONFIG_DEBUG_STACKOVERFLOW enabled. It will 
track and (if it can be done safely) print out maximum stack usage sites 
immediately. Hopefully this results in better stackdumps. It should 
print similar traces:

----------------------------->
| new stack-footprint maximum: smartd/1747, 1768 bytes.
------------|
 [<c013c1b6>] check_raw_flags+0xb/0x55 (8)
 [<c013ebeb>] sub_preempt_count+0x1a/0x1c (8)
 [<c013cb28>] __mcount+0x6a/0x91 (28)
 [<c013c3ff>] irqs_disabled+0x8/0x19 (16)
 [<c013c7b5>] ____trace+0x9e/0x208 (4)
 [<c01142d8>] mcount+0x14/0x18 (24)
 [<c013c3ff>] irqs_disabled+0x8/0x19 (20)
 [<c013c7b5>] ____trace+0x9e/0x208 (8)
 [<c013f145>] trace_stop_sched_switched+0x40/0x17d (8)
 [...]

i've written a separate, hopefully more robust stack-dumper which is 
used for the above traces. Perhaps in your overflow case it results in 
something usable.

	Ingo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/