Messages in this thread | | | Date | Thu, 30 Mar 2006 13:55:12 +1100 | From | Nick Piggin <> | Subject | Re: 2.6.16-rt10 crash on ppc |
| |
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
- 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/
| |