On Fri, Sep 18, 2009 at 2:28 AM, Michael Blizek <
[email protected]> wrote:
> Hi!
>
> On 23:43 Thu 17 Sep , Leonidas . wrote:
>
> ...
>
> > 1. My profiling functions might do following in worst case
> > {
> > Part 1
> > spinlock
> > populate a tree & search a tree & delete a node from tree
> > spinunlock
>
> This looks interesting. Searching a tree and deleting a node should not
> take
> *that* long. However, populating a tree might take some time. Can you do
> this
> in background? e.g.:
>
> 1) alloc memory for the tree
> 2) populate it
> 3) spinlock
> 4) change the pointer to the new tree
> 5) unlock
>
> > Part 2
> > Lock
> > Update an error buffer
> > Unlock
> > }
> > Which might be quite an overhead for an ISR.
> >
> > 2. in_interrupt would do for me.
> > 3. My module would be single threaded, unless I strictly required.
> >
> > The whole issue is to lock the update error buffer i.e. part 2 above.
> > This buffer updated from part 2 would be read in read method of module.
> >
> > -Leo.
>
> This does not look like a big problem to me. You cannot do copy_to_user
> while
> holding a spinlock anyway, because copy_to_user might have to sleep, if the
> user space memory is swapped out. You can copy the error buffer into a
> local
> buffer while holding the spinlock and than copy the local buffer into
> userspace in syscall context without holding any lock.
>
> -Michi
> --
> programing a layer 3+4 network protocol for mesh networks
> see http://michaelblizek.twilightparadox.com
>
>
If I am not wrong, you are hinting something like RCU. Actually I had
something like this in mind earlier, will explore this issue again later.
For the first cut of my module I am planning to go ahead with spinlocks.
Since there are not many options there, either RCU/What you say/spinlocks.
About the copy_to_user part, certainly this is not an issue. I am planning
to
use spinlocks here too and copy_to_user will be done outside that.
Thanks for the input.
-Leo.
