lkml.org 
[lkml]   [2006]   [Mar]   [30]   [last100]   RSS Feed
Views: [more markup]  [less markup]  [headers]  [forward] 
 
Messages in this thread
/
DateThu, 30 Mar 2006 13:55:12 +1100
FromNick Piggin <>
SubjectRe: 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/

\
 
 \ /
  Last update: 2006-03-30 08:01    [from the cache]
©2003-2008