From owner-svn-src-projects@FreeBSD.ORG Mon Oct 29 01:45:32 2012 Return-Path: Delivered-To: svn-src-projects@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 27EEC6FF; Mon, 29 Oct 2012 01:45:32 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from mail-la0-f54.google.com (mail-la0-f54.google.com [209.85.215.54]) by mx1.freebsd.org (Postfix) with ESMTP id 89D3F8FC0A; Mon, 29 Oct 2012 01:45:30 +0000 (UTC) Received: by mail-la0-f54.google.com with SMTP id e12so4382213lag.13 for ; Sun, 28 Oct 2012 18:45:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=+JJupYGBhMEHCwUkJGGc645038+9Cq91cERxFpZz7zo=; b=v/AofRWO84/zVXiW+wSdM+DzQyst8CHLIWK11ee3i5V0sxSvBln5lXwR3gLomu0/cb 1UOzgOnJTHwnFT49zwjCvMie6oCAx/OpfcUthjDY+SXvE9yXaEX8eGaakKKRQcpC0u5+ ROg92jqy6bRA1cSg0/fFBqj8enld3UZxFxAV0+u4sKCdRSitikm0mTNbIJVvZoY82fgy yC59npNhRnngAuJBg0n6XSAc4YVkAz948AC/UD/IDuhekG1hImc2WOciTROrcHfAluaV CVT5uUU2k1Q3k03XxukW4Zu4H8WWVNaT7O9TQ8G/PqRJ8q6/iTm6zT8YXcsm+AM7o+ad ZgSQ== MIME-Version: 1.0 Received: by 10.112.47.129 with SMTP id d1mr11085132lbn.115.1351475129237; Sun, 28 Oct 2012 18:45:29 -0700 (PDT) Sender: asmrookie@gmail.com Received: by 10.112.30.37 with HTTP; Sun, 28 Oct 2012 18:45:28 -0700 (PDT) In-Reply-To: References: <201207301350.q6UDobCI099069@svn.freebsd.org> <201207301732.33474.jhb@freebsd.org> Date: Mon, 29 Oct 2012 01:45:28 +0000 X-Google-Sender-Auth: SxkfPPHXlO8-xg8EgMzO_qM5DjU Message-ID: Subject: Re: svn commit: r238907 - projects/calloutng/sys/kern From: Attilio Rao To: John Baldwin Content-Type: text/plain; charset=UTF-8 Cc: svn-src-projects@freebsd.org, Jeff Roberson , src-committers@freebsd.org, Bruce Evans , Florian Smeets X-BeenThere: svn-src-projects@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: attilio@FreeBSD.org List-Id: "SVN commit messages for the src " projects" tree" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Oct 2012 01:45:32 -0000 On Wed, Oct 10, 2012 at 5:49 PM, Attilio Rao wrote: > On Tue, Sep 18, 2012 at 1:13 AM, Attilio Rao wrote: >> On Thu, Aug 2, 2012 at 9:56 PM, Attilio Rao wrote: >>> On 7/30/12, John Baldwin wrote: >> >> [ trimm ] >> >>>> --- //depot/projects/smpng/sys/kern/kern_rmlock.c 2012-03-25 >>>> 18:45:29.000000000 0000 >>>> +++ //depot/user/jhb/lock/kern/kern_rmlock.c 2012-06-18 21:20:58.000000000 >>>> 0000 >>>> @@ -70,6 +70,9 @@ >>>> } >>>> >>>> static void assert_rm(const struct lock_object *lock, int what); >>>> +#ifdef DDB >>>> +static void db_show_rm(const struct lock_object *lock); >>>> +#endif >>>> static void lock_rm(struct lock_object *lock, int how); >>>> #ifdef KDTRACE_HOOKS >>>> static int owner_rm(const struct lock_object *lock, struct thread >>>> **owner); >>> >>> While here, did you consider also: >>> - Abstracting compiler_memory_barrier() into a MI, compiler dependent function? >> >> So what do you think about this patch? (Please double-check the GIT log). > > The real reason why I wanted an abstract __compiler_membar() was to > cleanly fix a bug that I think affects sched_pin()/sched_unpin() right > now. Now that sched_pin()/sched_unpin() are fixed I would like to introduce this new patch, making critical_enter()/critical_exit() inline: http://www.freebsd.org/~attilio/inline_critical.patch The concept is pretty simple: simple add/dec for critical_enter, exit are inlined, the rest is in an "hard path". Debugging enables the hard paths by default (really I think that only KTR may be due here, but I thought that in case of INVARIANTS this was also wanted, so I added the check also for that case). flo@ has stress-tested the patch already and he may be starting serious benchmarks soon. The effectiveness of this patch is to determine and it brings again the question: better an hard function or the usage of compiler membars to avoid issues? I think that this patch should be in only if we can absolutely prove a measurable performance bump, otherwise I will just add a note to critical_enter()/critical_exit() explaining why they should not be inlined at all. Opinions? Thanks, Attilio -- Peace can only be achieved by understanding - A. Einstein