- Potential performance bottleneck for Linxu TCP
in [Kernel]
|
From: Christoph Hellwig on 30 Nov 2006 04:40 On Wed, Nov 29, 2006 at 07:56:58PM -0600, Wenji Wu wrote: > Yes, when CONFIG_PREEMPT is disabled, the "problem" won't happen. That is why I put "for 2.6 desktop, low-latency desktop" in the uploaded paper. This "problem" happens in the 2.6 Desktop and Low-latency Desktop. CONFIG_PREEMPT is only for people that are in for the feeling. There is no real world advtantage to it and we should probably remove it again. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Evgeniy Polyakov on 30 Nov 2006 05:00 On Thu, Nov 30, 2006 at 08:35:04AM +0100, Ingo Molnar (mingo(a)elte.hu) wrote: > what was observed here were the effects of completely throttling TCP > processing for a given socket. I think such throttling can in fact be > desirable: there is a /reason/ why the process context was preempted: in > that load scenario there was 10 times more processing requested from the > CPU than it can possibly service. It's a serious overload situation and > it's the scheduler's task to prioritize between workloads! > > normally such kind of "throttling" of the TCP stack for this particular > socket does not happen. Note that there's no performance lost: we dont > do TCP processing because there are /9 other tasks for this CPU to run/, > and the scheduler has a tough choice. > > Now i agree that there are more intelligent ways to throttle and less > intelligent ways to throttle, but the notion to allow a given workload > 'steal' CPU time from other workloads by allowing it to push its > processing into a softirq is i think unfair. (and this issue is > partially addressed by my softirq threading patches in -rt :-) Doesn't the provided solution is just a in-kernel variant of the SCHED_FIFO set from userspace? Why kernel should be able to mark some users as having higher priority? What if workload of the system is targeted to not the maximum TCP performance, but maximum other-task performance, which will be broken with provided patch. > Ingo -- Evgeniy Polyakov - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Nick Piggin on 30 Nov 2006 05:10 Evgeniy Polyakov wrote: > On Thu, Nov 30, 2006 at 08:35:04AM +0100, Ingo Molnar (mingo(a)elte.hu) wrote: > Doesn't the provided solution is just a in-kernel variant of the > SCHED_FIFO set from userspace? Why kernel should be able to mark some > users as having higher priority? > What if workload of the system is targeted to not the maximum TCP > performance, but maximum other-task performance, which will be broken > with provided patch. David's line of thinking for a solution sounds better to me. This patch does not prevent the process from being preempted (for potentially a long time), by any means. -- SUSE Labs, Novell Inc. Send instant messages to your online friends http://au.messenger.yahoo.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Evgeniy Polyakov on 30 Nov 2006 05:30 On Thu, Nov 30, 2006 at 09:07:42PM +1100, Nick Piggin (nickpiggin(a)yahoo.com.au) wrote: > >Doesn't the provided solution is just a in-kernel variant of the > >SCHED_FIFO set from userspace? Why kernel should be able to mark some > >users as having higher priority? > >What if workload of the system is targeted to not the maximum TCP > >performance, but maximum other-task performance, which will be broken > >with provided patch. > > David's line of thinking for a solution sounds better to me. This patch > does not prevent the process from being preempted (for potentially a long > time), by any means. It steals timeslices from other processes to complete tcp_recvmsg() task, and only when it does it for too long, it will be preempted. Processing backlog queue on behalf of need_resched() will break fairness too - processing itself can take a lot of time, so process can be scheduled away in that part too. > -- > SUSE Labs, Novell Inc. > Send instant messages to your online friends http://au.messenger.yahoo.com -- Evgeniy Polyakov - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Wenji Wu on 30 Nov 2006 11:20
>We can make explicitl preemption checks in the main loop of >tcp_recvmsg(), and release the socket and run the backlog if >need_resched() is TRUE. >This is the simplest and most elegant solution to this problem. I am not sure whether this approach will work. How can you make the explicit preemption checks? For Desktop case, yes, you can make the explicit preemption checks at some points whether need_resched() is true. But when need_resched() is true, you can not decide whether it is triggered by higher priority processes becoming runnable, or the process within tcp_recvmsg being expiring. If the higher prioirty processes become runnable (e.g., interactive process), you better yield the CPU, instead of continuing this process. If it is the case that the process within tcp_recvmsg() is expriring, then, you can continue the process to go ahead to process backlog. For Low-latency Desktop case, I believe it is very hard to make the checks. We do not know when the process is going to expire, or when higher priority process will become runnable. The process could expire at any moment, or higher priority process could become runnnable at any moment. If we do not want to tradeoff system responsiveness, where do you want to make the check? If you just make the chekc, then need_resched() become TRUE, what are you going to do in this case? wenji - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |