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();
next prev parent 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