Messages in this thread | | | Date | Mon, 13 Mar 2000 14:00:24 +0100 (CET) | From | Ingo Molnar <> | Subject | Re: new IRQ scalability changes in 2.3.48 |
| |
On Thu, 9 Mar 2000, Andrea Arcangeli wrote:
> >> Having said this, i now do agree that doing a preemptible kernel (which > >> the Linux SMP kernel could become with a small amount of work) is a > >> superior solution to this, wrt. latencies. > > Ingo, how do you plan to handle the by-hand locks? You can trivially > forbid rescheduling as soon as you have a spin_lock() held, but how do you > handle code that uses a spinlock to serialize the accesses to a lock?
well, such code has to be fixed/changed. There are other (i believe nastier) cases as well: rescheduling processes holding critical semaphores. All the lock inversion scenarios pop up full force in a preemptible kernel :-)
> And since most of the stuff needs some kind of serialization it also mean > for most of syscalls you are going to reschedule in the ret_from_syscall > stage anyway as now.
yep - a preemptible kernel does impact performance, no doubt about it. But the real cost is in the UP kernel: spinlocks are not a no-op with preemtible kernels anymore. (this can be helped with, but it's still additional code)
> I think one of the only interesting places for the preemtable kernel is > copy user stuff that will effectivly be rescheduled as soon as it's > necessary.
i'm not sure. Basically we have moved away from unbound copies, so i doubt any code in the kernel does more than a 64k copy at once to/from user-space. The typical copy is not bigger than 4k. So an explicit preemption point does help.
A 'fully preemtive' kernel is almost certainly a loss for typical systems, but it's quite useful for RT applications. (it might also be useful for interactive applications, although we are pretty good already with the lowlatency-patch.)
> But now by thinking at that stuff I have an idea! Why instead of making > the kernel preemtable we take the other way around? So why instead of > having to forbid scheduling in locked regions, we don't simply allow > rescheduling in some piece of code that we know that will benefit by the > preemtable thing?
this is way too ugly and non-generic. You are completely missing the point. uaccess.h latencies are _not_ the problem.
> That's all. Then we'll have copu_user preemtable with a few lines of > changes. I'll try that immediatly :).
Andrea, please think first and do not duplicate work done by others. A preemtive kernel is _not_ an issue unless you are into RT applications which need 100 usec-type latencies. A current kernel's interactive performance is already good enough to never show up in interactive applications. Those few multimedia applications which need 0.5ms-ish latencies are helped by the lowlatency patch.
Ingo
- 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/
| |