From owner-freebsd-current@FreeBSD.ORG  Mon Oct 11 15:37:43 2004
Return-Path: <owner-freebsd-current@FreeBSD.ORG>
Delivered-To: freebsd-current@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
	by hub.freebsd.org (Postfix) with ESMTP
	id 5206216A4CE; Mon, 11 Oct 2004 15:37:43 +0000 (GMT)
Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2])
	by mx1.FreeBSD.org (Postfix) with ESMTP
	id 2341A43D39; Mon, 11 Oct 2004 15:37:43 +0000 (GMT)
	(envelope-from dillon@apollo.backplane.com)
Received: from apollo.backplane.com (localhost [127.0.0.1])
	i9BFbdvA084691;	Mon, 11 Oct 2004 08:37:39 -0700 (PDT)
	(envelope-from dillon@apollo.backplane.com)
Received: (from dillon@localhost)
	by apollo.backplane.com (8.12.9p2/8.12.9/Submit) id i9BFbca1084688;
	Mon, 11 Oct 2004 08:37:38 -0700 (PDT)
	(envelope-from dillon)
Date: Mon, 11 Oct 2004 08:37:38 -0700 (PDT)
From: Matthew Dillon <dillon@apollo.backplane.com>
Message-Id: <200410111537.i9BFbca1084688@apollo.backplane.com>
To: Sam Lawrance <boris@brooknet.com.au>
References: <Pine.NEB.3.96L.1041011045403.31040K-100000@fledge.watson.org>
	<1097500052.2797.10.camel@dirk.no.domain>
cc: freebsd-current@freebsd.org
cc: Robert Watson <rwatson@freebsd.org>
cc: David Xu <davidxu@freebsd.org>
Subject: Re: Noticable Delays Since Beta 3 (possible cause)
X-BeenThere: freebsd-current@freebsd.org
X-Mailman-Version: 2.1.1
Precedence: list
List-Id: Discussions about the use of FreeBSD-current
	<freebsd-current.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-current>,
	<mailto:freebsd-current-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-current>
List-Post: <mailto:freebsd-current@freebsd.org>
List-Help: <mailto:freebsd-current-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-current>,
	<mailto:freebsd-current-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Mon, 11 Oct 2004 15:37:43 -0000

    I would not recommend putting proc0 wakeup code in your time-critical
    critical section code.  It's a terrible hack and an abuse of the purpose
    of the critical section code and right smack in the middle of a very
    important critical path that effects the performance of the *entire*
    system.

    I would also not recommend having a TDP_WAKEPROC0 flag for curproc,
    that's a terrible hack and a misplaced flag (the flag, if you have one
    at all, should be global or per-cpu, and certainly *NOT* placed in
    the current thread's flagset!).

    It seems to me the proper solution is to use the same codepath that
    woke up proc0 originally (in 4.x), which in 5.x/6.x has now become
    sleepq_broadcast().  Check to see if proc0 needs to be woken up there,
    in the code that moves the threads from the sq to the temporary list,
    and if one of them needs proc0 just flag it and then lock whatever
    sleepq list proc0 is on and pull it off too before you hit the
    sleepq_resume_thread() loop.

						-Matt