Messages in this thread | | | Date | Thu, 18 Mar 2004 12:18:26 -0800 | From | Andrew Morton <> | Subject | Re: [PATCH 2.6] serialization of kernelcapi work |
| |
Armin Schindler <armin@melware.de> wrote: > > Hi all, > > the ISDN kernelcapi function recv_handler() is triggered by > schedule_work() and dispatches the CAPI messages to the applications. > > Since a workqueue function may run on another CPU at the same time, > reordering of CAPI messages may occur.
TCP has the same problem.
> For serialization I suggest a mutex semaphore in recv_handler(), > patch is appended (yet untested).
It will work OK. It isn't very scalable of course, but I assume you're dealing with relatively low bandwidths.
I would suggest that you look at avoiding the global semaphore. Suppose someone has 64 interfaces or something. Is that possible? It might be better to put the semaphore into struct capi_ctr so you can at least process frames from separate cards in parallel.
> Is there a better way to do user-context work serialized ?
Not really - you've been bitten by the compulsory per-cpuness of the workqueue handlers.
You could have a standalone kernel thread or always queue the work onto CPU #0 (the function to do this isn't merged, but exists). But both these are unscalable.
So apart from moving recv_handler_lock into struct capi_ctr I can't think of anything clever.
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |