libblock performance question

[Till Straumann]

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?

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?

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.

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...

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.
>>>
>>
>