lkml.org 
[lkml]   [2006]   [Nov]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    SubjectRe: [patch 1/4] - Potential performance bottleneck for Linxu TCP
    From
    From: Ingo Molnar <mingo@elte.hu>
    Date: Thu, 30 Nov 2006 07:17:58 +0100

    >
    > * David Miller <davem@davemloft.net> wrote:
    >
    > > 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.
    >
    > yeah, i like this one. If the problem is "too long locked section", then
    > the most natural solution is to "break up the lock", not to "boost the
    > priority of the lock-holding task" (which is what the proposed patch
    > does).

    Ingo you're mis-read the problem :-)

    The issue is that we actually don't hold any locks that prevent
    preemption, so we can take preemption points which the TCP code
    wasn't designed with in-mind.

    Normally, we control the sleep point very carefully in the TCP
    sendmsg/recvmsg code, such that when we sleep we drop the socket
    lock and process the backlog packets that accumulated while the
    socket was locked.

    With pre-emption we can't control that properly.

    The problem is that we really do need to run the backlog any time
    we give up the cpu in the sendmsg/recvmsg path, or things get real
    erratic. ACKs don't go out as early as we'd like them to, etc.

    It isn't easy to do generically, perhaps, because we can only
    drop the socket lock at certain points and we need to do that to
    run the backlog.

    This is why my suggestion is to preempt_disable() as soon as we
    grab the socket lock, and explicitly test need_resched() at places
    where it is absolutely safe, like this:

    if (need_resched()) {
    /* Run packet backlog... */
    release_sock(sk);
    schedule();
    lock_sock(sk);
    }

    The socket lock is just a by-hand binary semaphore, so it doesn't
    block pre-emption. We have to be able to sleep while holding it.
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2006-11-30 07:33    [W:0.022 / U:94.332 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site