Messages in this thread | | | Date | Tue, 14 Mar 2000 01:07:25 +0100 (CET) | From | Ingo Molnar <> | Subject | Re: new IRQ scalability changes in 2.3.48 |
| |
On Mon, 13 Mar 2000, Linus Torvalds wrote:
> We want to avoid having long latencies, and we can easily get that by > just allowing timer interrupts to schedule which we're in a big > "memcpy_to_user()" and we don't hold any kernel lock etc. No need to > try to be clever at lock release time - if we get a pending > reschedule, we might as well leave it pending, it's going to be > serviced soon enough anyway.
yep - and the 'natural blocking' of memcpys is bound (in size) anyway, so the conditional reschedule is probably faster (and an already proven solution). I believe there is one more reason to allow a memcpy to finish before rescheduling: the source buffer is often (especially in the networking case) already cached, so we are better off if we wait 100 usecs and reschedule _after_ the memcpy.
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/
| |