public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Ingo Molnar <mingo@elte.hu>
To: Nick Piggin <nickpiggin@yahoo.com.au>
Cc: emin ak <eminak71@gmail.com>, linux-kernel@vger.kernel.org
Subject: Re: 2.6.16-rt10 crash on ppc
Date: Wed, 29 Mar 2006 17:08:15 +0200	[thread overview]
Message-ID: <20060329150815.GA24741@elte.hu> (raw)
In-Reply-To: <44288FB3.5030208@yahoo.com.au>


* Nick Piggin <nickpiggin@yahoo.com.au> 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();

  reply	other threads:[~2006-03-29 15:11 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-03-27 14:56 2.6.16-rt10 crash on ppc emin ak
2006-03-27 17:11 ` emin ak
2006-03-27 20:31 ` emin ak
2006-03-28  1:21   ` Nick Piggin
2006-03-29 15:08     ` Ingo Molnar [this message]
2006-03-30  2:55       ` Nick Piggin
2006-03-30  7:13         ` Ingo Molnar
2006-03-30  7:18           ` Kumar Gala
2006-03-30  7:23             ` Ingo Molnar
2006-03-30 10:25               ` emin ak
2006-03-30 11:34                 ` Ingo Molnar
2006-03-30 14:55                   ` emin ak

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=20060329150815.GA24741@elte.hu \
    --to=mingo@elte.hu \
    --cc=eminak71@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=nickpiggin@yahoo.com.au \
    /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