libblock performance question

[Till Straumann]

Joel Sherrill wrote:

>
>Till Straumann wrote:
>
>>Eugeny S. Mints wrote:
>>
>>>On Mon, 14 Oct 2002, Joel Sherrill wrote:
>>>
>>>>Till Straumann wrote:
>>>>
>>>>>Hi.
>>>>>
>>>>>I am thinking about using libblock for implementing an NFS client.
>>>>>However, I am a little bit concerned about libblock using task
>>>>>preemption disabling. Code that is executed with preemption
>>>>>disabled is not trivially short - therefore, I am a bit concerned that
>>>>>using libblock might degrade dispatching latency for high priority tasks
>>>>>(who possibly are not using a FS or libblock whatsoever).
>>>>>
>>>>>Can anybody resolve my doubts?
>>>>>
>>>>I didn't do any extensive algorithmic analysis but I don't see anything
>>>>particularly alarming.  There were a handful of DISABLE_PREEMPTION
>>>>macro invocations in bdbuf.c.  Some protected AVL tree operations which
>>>>should not be O(n) but more like O(log2 n) so that isn't very bad.
>>>>You can have 255 blocks to manage and still only do 8 "operations."
>>>>
>>>>The other path seems to be freeing buffers and that is no worse
>>>>than any RTEMS internal critical section -- chain append + semaphore
>>>>release.
>>>>
>>>>Do you see any O(n) loops?
>>>>
>>Hmmm - it's just that protecting stuff by disabling preemption makes me
>>nervous (Joel: remember the malloc info incident?). IMHO, task preemption
>>should be avoided and only used for limited stretches of code. Is there
>>any good reason for _not_ using semaphore/mutex protection in libblock?
>>
>
>I asked that in an earlier response.  My impression was that the disable
>of preemption did not appear to be too long but using a mutex would be
>better.
>
>>Also, if I don't oversee something, it seems to me that just disabling task
>>preemption for mutual exclusion is not really SMP safe - is it?
>>
>
>It could be but it depends upon the synchronization between the CPUs.
>In the RTEMS MP model, it would be safe. 
>
So different CPUs live in different address spaces - only one CPU would 
effectively
execute libblock? Sorry - I'm not really familiar with the RTEMS MP 
model, as I just
realize...

>
>>Then: the code sections with task preemption disabled are not limited to
>>libblock/bdbuf but extend to the disk driver ioctl() -- who knows what
>>the disk
>>driver implementor does in his ioctl() - all with exclusive access
>>(except for
>>interrupts) to one CPU ?? Of course, I don't understand the last details
>>of the code but it seems to be safe to enable preemption around the ioctl()
>>calls.
>>
>
>I missed the ioctl() so that is an open hole.  Where is that call?  
>

One is in rtems_bdbuf_read(), the other one is done from the swapout task
(which is in non-preemptible mode).

BTW: it seems that "find_or_assign_buffer()", when executing the 'goto 
again' branch,
repeatedly acquires the bufget_sema...

-- Till


>
>
>>BTW, Eugeny: It seems that the swapout task releases the disk _before_ it
>>obtains the transfer_sema - is that OK?
>>
>>I apologize for stirring up these issues but IMO you can never be careful
>>enough...
>>
>
>No you can't be.  Great performance can be fragile. :)
>
>>Regards
>>-- Till
>>
>>>I have answered to Till exactly the same yesterday but
>>>unfortunately it seems the letter doesn't reatch rtems-user
>>>list even though the address was in CC :( (seems because
>>>I've answered from not usual e-mail address and list filter
>>>drop it)
>>>
>>>>Looking at this, I don't see why DISABLE_PREEMPTION couldn't be
>>>>replaced with a mutex though.
>>>>
>>>>>Cheers,
>>>>>--Till.
>>>>>
>