Messages in this thread | | | Date | Thu, 9 Mar 2000 12:27:25 +0100 (CET) | From | Andrea Arcangeli <> | Subject | Re: new IRQ scalability changes in 2.3.48 |
| |
On Mon, 13 Mar 2000, Ingo Molnar wrote:
>we would still not switch out of IRQ contexts. IRQ contexts (including >softirqs, tasklets and bhs) are supposed to be atomic and time-bound. A >preemptive Linux kernel simply does a context switch if 1) ->need_resched >is set 2) we return to a non-IRQ context (which can be either user-space >or kernel-space). There is nothing magic about this, SMP does not
I instead propose to not make the kernel preemtable but to take the other way around marking some special section as preemtable.
if (need_resched is set && (the irq happened on top of userspace || atomic_read(&cpu_preemtable) is != 0)) reschedule()
That won't harm the locking fast path (as a preemtable kernel would do), it won't have side effects and it will provide the same low latency for the copy_user (or similar section of code) without having to add the ugly and slow explicit checks for need_resched.
Comments?
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/
| |