compatibility layer - workqueues

[Adrian Chadd]

Is there some magic to do with spinlock versus spinlock_bh that we
don't necessarily have with your lock/mutex operations?

If any spinlocks grab bh locks in Linux then a bunch of work on other
CPUs gets disabled.



adrian

On 20 May 2013 21:56, Orit Moskovich <oritm at mellanox.com> wrote:
> Hi,
>
> I'm working on understanding the difference between Linux and FreeBSD interrupt handling.
> I looked at the compatibility layer and noticed this:
>
>
> *         Linux workqueues are implemented using FreeBSD taskqueues (under sys/ofed/include/linux/workqueue.h)
>
> *         In linux, the function schedule_work() puts a job in the kernel global workqueue 'events'. This workqueue consists of worker threads - one per processor
>
> *         The compatibility layer wraps this function to a macro, that implements the functionality using taskqueue_enqueue() and set it to work on taskqueue_thread, that executes its tasks in the context of a kernel thread
>
> *         BUT,  taskqueue_thread is initialized in:
>
> o   sys/kern/subr_taskqueue.c  line 536:
> TASKQUEUE_DEFINE_THREAD(thread);
>
> o   which is defined in sys/taskqueue.h line 133
> and run taskqueue_start_threads() with only 1 thread, and not MAXCPU
>
>
>
> I'll appreciate your help understanding this issue,
>
>
>
> Thanks,
>
> Orit Moskovich
>
>
> _______________________________________________
> freebsd-arch at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-arch
> To unsubscribe, send any mail to "freebsd-arch-unsubscribe at freebsd.org"