Re: 2.6.16-rt10 crash on ppc

[Ingo Molnar]

* Nick Piggin <nickpiggin@xxxxxxxxxxxx> wrote:

> Normally what will happen is that kswapd will be woken up, and 
> ksoftirqd will start throttling (soft) interrupts and kswapd will be 
> allowed to get a chance to run. With the -rt kernel, I guess if your 
> network irq has a higher priority than kswapd, it could prevent it 
> from running completely. (I could be wrong here).
> 
> You might try increasing /proc/sys/vm/min_free_kbytes, or failing 
> that, increase the priority of kswapd to something comparable to or 
> greater than your network interrupt.
> 
> I'm not very familiar with the -rt tree, but possibly what should be 
> happening, if interrupts are executed in process context and allowed 
> to schedule, is that their memory allocations should also be allowed 
> to reclaim memory.

indeed - very good point. Emin, could you try the patch below [which 
isnt a full solution but should be a good first approximation], does it 
make any difference?

> OTOH, I guess for a deterministic realtime system, you need to 
> allocate fixed minimum amounts of memory for each element of the 
> system so you never run out like this.

yeah, preallocation is pretty much the only way to go for deterministic 
workloads. Still, networking (and other complex subsystems) can still be 
used in parallel to deterministic tasks - and those should not be 
starved easier when PREEMPT_RT is enabled. In fact, with the patch below 
it could become much more robust - we could in fact achieve to never 
fail an allocation due to being in an atomic context.

	Ingo

Index: linux/mm/page_alloc.c
===================================================================
--- linux.orig/mm/page_alloc.c
+++ linux/mm/page_alloc.c
@@ -1008,9 +1008,11 @@ nofail_alloc:
 		goto nopage;
 	}
 
+#ifndef CONFIG_PREEMPT_RT
 	/* Atomic allocations - we can't balance anything */
 	if (!wait)
 		goto nopage;
+#endif
 
 rebalance:
 	cond_resched();
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/