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
--
To unsubscribe from this list: send an email with
"unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx
Please read the FAQ at http://kernelnewbies.org/FAQ
