From: Nick Piggin <nickpiggin@yahoo.com.au>
To: Ingo Molnar <mingo@elte.hu>
Cc: emin ak <eminak71@gmail.com>, linux-kernel@vger.kernel.org
Subject: Re: 2.6.16-rt10 crash on ppc
Date: Thu, 30 Mar 2006 13:55:12 +1100 [thread overview]
Message-ID: <442B4890.6000905@yahoo.com.au> (raw)
In-Reply-To: <20060329150815.GA24741@elte.hu>
Ingo Molnar wrote:
>* Nick Piggin <nickpiggin@yahoo.com.au> wrote:
>
>>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.
>
>
Yes, that patch is basically what I had in mind.
Is -rt ever allocating memory from really-hard-don't-preempt-me context?
I guess not, unless the zone->lock is one of those locks too, right?
Should you add a
#else
BUG_ON(_really_dont_preempt_me());
#endif
just for safety, or will such misusage get caught elsewhere (eg. when
attempting to take zone->lock).
Thanks,
Nick
--
Send instant messages to your online friends http://au.messenger.yahoo.com
next prev parent reply other threads:[~2006-03-30 5:59 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
2006-03-30 2:55 ` Nick Piggin [this message]
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=442B4890.6000905@yahoo.com.au \
--to=nickpiggin@yahoo.com.au \
--cc=eminak71@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.