libblock performance question

[Joel Sherrill]

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.

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

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

-- 
Joel Sherrill, Ph.D.             Director of Research & Development
joel at OARcorp.com                 On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
   Support Available             (256) 722-9985