From owner-freebsd-arch@FreeBSD.ORG Tue Jun 24 02:09:44 2014 Return-Path: Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A3643D83; Tue, 24 Jun 2014 02:09:44 +0000 (UTC) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7::25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.netbsd.org", Issuer "Postmaster NetBSD.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 758DF2EF7; Tue, 24 Jun 2014 02:09:44 +0000 (UTC) Received: from ws (localhost [IPv6:::1]) by mail.netbsd.org (Postfix) with SMTP id 9A2BF14A247; Tue, 24 Jun 2014 02:09:41 +0000 (UTC) Date: Tue, 24 Jun 2014 03:09:41 +0100 From: Mindaugas Rasiukevicius To: Mateusz Guzik Subject: Re: PoC: passive serialization In-Reply-To: <20140622123457.GA20525@dft-labs.eu> References: <539FEBC1.5030501@FreeBSD.org> <20140621231853.394A914A2D0@mail.netbsd.org> <20140622123457.GA20525@dft-labs.eu> X-Mailer: mail(1) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-Id: <20140624020942.9A2BF14A247@mail.netbsd.org> Cc: Andrey Zonov , freebsd-arch@FreeBSD.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jun 2014 02:09:44 -0000 Mateusz Guzik wrote: > Cursory look suggests passive serialization got very limited use in > NetBSD, I was also unable to find any benchmarks. We have been avoiding RCU-like synchronisation in favour of alternative techniques. Passive serialisation was added relatively recently. Also, in many cases we can get away with a simpler way to ensure the quiescent state (c.f. xc_broadcast(9) calls will nullop in the NetBSD tree). As for benchmarks: well, benchmarks of what? The writer side? It is very expensive and slow. However, this is exactly what passive serialisation promises: extremely low cost on the reader side and very expensive writer side. The writer side can be improved by garbage collecting the items in a batch (and NetBSD interface allows the caller to do that). However, if the reader-writer ratio is not significantly dominated by the readers and the potential pressure on memory is not desirable, then you hit the limits of passive serialisation. At this point, if you are trying to address those limitations - you are basically (re)implementing RCU. At least, in a sense of heading towards the area covered by its patent portfolio. And that may be a bit tricky. > I do understand and appreciate your cautious approach, but it also > limits the potential. > > Do you have any materials which would show gains of using the concept as > implemented in your code? Right now it is unclear if the implementation > limited to this patent can yield benefits which would justify added > complexity. I think you miss the point. A lot of that machinery (three queues, extra bitmasks, etc) is either redundant or could be done a simpler/better way. It is there to implement the claims of the lapsed patent. There are no technical gains (quite the opposite). The gain is the reduced risk. It is up to you which approach do you want to take. I am just suggesting to put some thought on non-technical aspects of this problem as well. -- Mindaugas