On Fri, Sep 18, 2009 at 2:28 AM, Michael Blizek <michi1@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> wrote:
Hi!
On 23:43 Thu 17 Sep , Leonidas . wrote:
...
This looks interesting. Searching a tree and deleting a node should not take
> 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
*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
This does not look like a big problem to me. You cannot do copy_to_user while
> 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.
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.
