From owner-freebsd-hackers@FreeBSD.ORG Thu Sep 20 11:04:28 2012 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id BD4C0106566B; Thu, 20 Sep 2012 11:04:28 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id A1B508FC15; Thu, 20 Sep 2012 11:04:27 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id OAA15337; Thu, 20 Sep 2012 14:04:25 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1TEeYS-000ELe-Mm; Thu, 20 Sep 2012 14:04:24 +0300 Message-ID: <505AF836.7050004@FreeBSD.org> Date: Thu, 20 Sep 2012 14:04:22 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:15.0) Gecko/20120913 Thunderbird/15.0.1 MIME-Version: 1.0 To: attilio@FreeBSD.org References: <50587F8D.9060102@FreeBSD.org> <5058C68B.1010508@FreeBSD.org> <50596019.5060708@FreeBSD.org> In-Reply-To: X-Enigmail-Version: 1.4.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-hackers , Jeff Roberson Subject: Re: ule+smp: small optimization for turnstile priority lending X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Sep 2012 11:04:28 -0000 on 19/09/2012 10:33 Attilio Rao said the following: > It is hard for me to tell if this is subject to same issues because I > do not entirely understand where the locking was happening in your > patch. > Can you try testing this with your already KTR instrumented test and > possibly report? The patch works well as far as I can tell. Thank you! There is one warning with full witness enables but it appears to be harmless (so far): Acquiring duplicate lock of same type: "sched lock" 1st sched lock 1 @ /usr/src/sys/kern/subr_turnstile.c:212 2nd sched lock 0 @ /usr/src/sys/kern/sched_ule.c:1244 KDB: stack backtrace: db_trace_self_wrapper() at 0xffffffff802d238a = db_trace_self_wrapper+0x2a kdb_backtrace() at 0xffffffff80555f4a = kdb_backtrace+0x3a _witness_debugger() at 0xffffffff8056e2bc = _witness_debugger+0x2c witness_checkorder() at 0xffffffff8056f759 = witness_checkorder+0x579 _mtx_lock_spin_flags() at 0xffffffff80504bcd = _mtx_lock_spin_flags+0x10d sched_pickcpu() at 0xffffffff80547829 = sched_pickcpu+0x199 sched_add() at 0xffffffff80547bdb = sched_add+0x14b sched_thread_priority() at 0xffffffff80548059 = sched_thread_priority+0x1c9 sched_lend_prio() at 0xffffffff80548344 = sched_lend_prio+0x14 propagate_priority() at 0xffffffff8056801e = propagate_priority+0x1ce turnstile_wait() at 0xffffffff8056959f = turnstile_wait+0x4ef _mtx_lock_sleep() at 0xffffffff805045f6 = _mtx_lock_sleep+0x486 _mtx_lock_flags() at 0xffffffff80504814 = _mtx_lock_flags+0x104 lock_mtx() at 0xffffffff805049ca = lock_mtx+0x1a _sleep() at 0xffffffff80524589 = _sleep+0x4f9 taskqueue_thread_loop() at 0xffffffff805664c8 = taskqueue_thread_loop+0xa8 fork_exit() at 0xffffffff804e5d6a = fork_exit+0x1aa fork_trampoline() at 0xffffffff806ea2ce = fork_trampoline+0xe -- Andriy Gapon