Messages in this thread | | | Date | Fri, 1 Oct 1999 20:28:23 +0200 (CEST) | From | Andrea Arcangeli <> | Subject | Re: Bottom halves. |
| |
On Fri, 1 Oct 1999, Roman Zippel wrote:
>as they can only run on a single cpu. Kernelthreads are far more flexible, >as they can run on multiple cpus and you can prioritize them. The only
One kernel thread can run in only one CPU at once. Exactly as bh handlers.
And bh handlers can run over all cpus but only one CPU can run the bh handlers at once.
So basically you should have smp_num_cpus kernel threads to scale better than bh and you'll pay the scheduling cost.
>locking stuff. That means every time a lock is hold, we also have to >forbid scheduling, that could be done with a simple increment. On the
The point is that while inside the kernel you'll held at least one lock for most of the time. So it would be no scheduling gain IMHO as to schedule you should unlock something by hand anyway (right now it's unlock; conditional schedule; lock).
Andrea
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |