Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 11 Oct 2004 08:37:38 -0700 (PDT)
From:      Matthew Dillon <dillon@apollo.backplane.com>
To:        Sam Lawrance <boris@brooknet.com.au>
Cc:        David Xu <davidxu@freebsd.org>
Subject:   Re: Noticable Delays Since Beta 3 (possible cause)
Message-ID:  <200410111537.i9BFbca1084688@apollo.backplane.com>
References:  <Pine.NEB.3.96L.1041011045403.31040K-100000@fledge.watson.org> <1097500052.2797.10.camel@dirk.no.domain>

next in thread | previous in thread | raw e-mail | index | archive | help
    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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200410111537.i9BFbca1084688>