Re: rt file i/o

[Tim Blechmann <tim@klingt.org>]

[-- Attachment #1: Type: text/plain, Size: 1625 bytes --]

On 11/04/2009 11:44 PM, Clark Williams wrote:
> On Wed, 04 Nov 2009 18:32:41 +0100
> Tim Blechmann <tim@klingt.org> wrote:
> 
>>>> well, if i understand the rt howto correctly, _no_ disc access is
>>>> allowed, neither from rt nor from non-rt threads, since it may produce
>>>> page faults, which introduce latencies ...
>>>
>>> I would be supprised if the rt howto states that page-faults in non-rt
>>> threads is a critical problem - that would not significantly impact RT
>>> performance - atelast not the worst case - it will (as every other system
>>> load) impact the average case. so having a non-rt thread reading disk-files
>>> to a buffer and a rt-thread processing this buffer should be perfectly fine.
>>
>> that is what i thought for years ... but according to [1] a page fault
>> in an rt process freezes the entire process with both rt and non-rt
>> threads until the page fault is handled ...
>>
> 
> No, we need to get that fixed in the wiki. It may have been the case
> that the entire process was frozen while a fault was being handled, but
> I don't believe that is the case now. If you're in a thread on core0
> and a sibling thread on core1 faults, you shouldn't be impacted unless
> you're trying to reference the same memory. 

well, then my application seems to be real-time safe ... it would be
nice if the wiki would reflect the current state of the rt-preempt
kernel, though ...

thnx, tim

-- 
tim@klingt.org
http://tim.klingt.org

All we composers really have to work with is time and sound - and
sometimes I'm not even sure about sound.
  Morton Feldman


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]