From owner-freebsd-arch@freebsd.org Mon Oct 30 16:39:00 2017 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A2E7EE6110B for ; Mon, 30 Oct 2017 16:39:00 +0000 (UTC) (envelope-from matt.joras@gmail.com) Received: from mail-qk0-f171.google.com (mail-qk0-f171.google.com [209.85.220.171]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 660066993B; Mon, 30 Oct 2017 16:39:00 +0000 (UTC) (envelope-from matt.joras@gmail.com) Received: by mail-qk0-f171.google.com with SMTP id k123so16923299qke.3; Mon, 30 Oct 2017 09:39:00 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=ujCquv5WrCANSxzvjL5b7OGBE6TMOOw45JiKHdIH4ng=; b=mlXeSYuwz5vAFPzX+tlEsKE2g4U8wceDMzsySyt3bFcQdq7a5HWb93BZDCfBXyY+Zj h3jtOfOTWL8E8OeVtBw5cR6HEBMaL3zC9HyYCKRIjsS6xbkRXranle1VCUtUZ47NiTEQ C3V3aZu87L/qGO81abqMhoyKgKANtnbsN2o46fAaBulHAZvssRTmNuMv4mAqPBKmoOVR ZkvafF5qHtG9iII/D3oxSExyCc3TpPXXe/Fd92VJ+gsra7hDqk+n1aE2NlO+NC+yuNxk Q7/hUzmjjEMhcqIYbWocT4igu+PaZjfnY7zUyu0GT/V6aEiS4R5xiEyZ53f/QXW2rqCu Uu5w== X-Gm-Message-State: AMCzsaU+Hzfp8vEV8cPd56N9rzYUXS/ymXpN3FYc41dtKgYWpkwu+UTQ 56hKsHZP7rMBBIVEpc5r2zxoe7C9 X-Google-Smtp-Source: ABhQp+Q8m39YOSHm69Oq8wdqpYB3eVFBnLB+MYykRdQ9gM0mq2sdHH+Qr+7L7uDLidyCBlVH5qpwQQ== X-Received: by 10.55.38.148 with SMTP id m20mr14438456qkm.151.1509381532364; Mon, 30 Oct 2017 09:38:52 -0700 (PDT) Received: from [192.168.2.123] (174-24-242-218.tukw.qwest.net. [174.24.242.218]) by smtp.gmail.com with ESMTPSA id z55sm10375536qth.24.2017.10.30.09.38.51 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 30 Oct 2017 09:38:51 -0700 (PDT) Subject: Re: Allow faster eventhandler dispatching by keeping pointers to handler lists. To: Ian Lepore , Hans Petter Selasky , "freebsd-arch@FreeBSD.org" References: <1509243567.56824.103.camel@freebsd.org> <3a71dd31-99cb-c891-9d52-a7f2e7010011@FreeBSD.org> <1509293552.21609.5.camel@freebsd.org> <1509294247.21609.12.camel@freebsd.org> <7b59ff3d-3458-0bca-e6b4-13454b13efb0@FreeBSD.org> <1509296624.21609.24.camel@freebsd.org> <0fad1391-726d-8215-075d-9411abdf6edb@selasky.org> <1509379503.21609.103.camel@freebsd.org> From: Matt Joras Message-ID: <54876119-9262-c15b-d3fe-1220cf7f17f6@FreeBSD.org> Date: Mon, 30 Oct 2017 09:38:49 -0700 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <1509379503.21609.103.camel@freebsd.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Content-Language: en-US X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Oct 2017 16:39:00 -0000 On 10/30/2017 09:05, Ian Lepore wrote: > On Mon, 2017-10-30 at 09:17 +0100, Hans Petter Selasky wrote: >> On 10/29/17 18:03, Ian Lepore wrote: >>> Oh.  Right.  Hmmm, I think malloc() is required to support the case >>> where a handler registers before the static list init is invoked, and I >>> do think that's a useful feature to preserve.  That means the lists >>> aren't really static, though, which then makes STATIC a bit out of >>> place in the new function/macro names. >> Why not use RCU here, and then update sys/queue.h to be RCU safe? >> >> --HPS > I'm not sure how that suggestion relates to that paragraph, but the > code already does use a form of RCU to handle deletion of registered > handlers from individual event lists.  It could probably benefit from a > rewrite to more fully embrace RCU and use it for insertions as well, > but that's beyond the scope of these changes, which are trying to > eliminate the worst uses of a global lock at a higher level than > maintaining the list for a single event. > > -- Ian Agreed. There are all sorts of clever things we can do with a more comprehensive rewrite. It would be a nice place to try out RCU-ish methods of handling object removal without locks. Matt