From owner-freebsd-arch@FreeBSD.ORG Wed Apr 28 12:20:02 2010 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4E14A106564A for ; Wed, 28 Apr 2010 12:20:02 +0000 (UTC) (envelope-from rwatson@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 0CD6B8FC13 for ; Wed, 28 Apr 2010 12:20:02 +0000 (UTC) Received: from lemongrass.sec.cl.cam.ac.uk (lemongrass.sec.cl.cam.ac.uk [128.232.18.47]) by cyrus.watson.org (Postfix) with ESMTPSA id 323EC46B0C; Wed, 28 Apr 2010 08:20:01 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1078) From: "Robert N. M. Watson" In-Reply-To: <06D5F9F6F655AD4C92E28B662F7F853E021D4D37@seaxch09.desktop.isilon.com> Date: Wed, 28 Apr 2010 13:19:59 +0100 Message-Id: References: <06D5F9F6F655AD4C92E28B662F7F853E021D4D37@seaxch09.desktop.isilon.com> To: Matthew Fleming X-Mailer: Apple Mail (2.1078) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-arch@freebsd.org Subject: Re: GDC/libdispatch for kernel X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Apr 2010 12:20:02 -0000 On 24 Apr 2010, at 20:29, Matthew Fleming wrote: > I have the need for a simple mechanism to farm off work blocks that = will be run on other processors if there is spare compute time, and on = the current CPU if there is not any spare time. >=20 > An example of something I want to do is compute an error correcting = code and a crc32 checksum on a block of data, potentially while also = dealing with system resources so the block can be written to disk. >=20 > I dont want to reinvent the wheel, and the GCD framework looks like it = would provide what I want in dispatch groups run on a parallel queue. = However, theres a lot of things supported in GCD that I dont need (now = and possibly ever). >=20 > Has anyone done any work to support some of the GCD functions in the = kernel? If not, how useful would other people find such a thing? In my = specific instance, I was thinking along the lines of having the idle = thread run a dispatch object off a global queue, setting its priority to = the curthread->td_priority of the thread that initiated the dispatch, in = order to prevent priority inversions. I dont want the farmed off work = to preempt anything else useful the system may have to do, which is why = I was considering the idle threads (or my own threads running at = PRI_MAX_IDLE-1 until they have work). >=20 > However, I dont think this implementation is really in the spirit of = the rest of the GCD architecture. So in addition to wondering if there = is an existing BSD-licensed code to do such a thing, I also am wondering = what direction the community can provide on a few design points to make = this useful both for me and for the general community. >=20 > I will be at BSDCan but I need something usable (for me, at least) = next week to fix some issues at work. >=20 > Meanwhile, one other question I had was regarding the name of all the = dispatch_foo_t objects, which are typedefs of a pointer-to-struct. This = is explicitly frowned upon in style(9), so would it be better to be = consistent with libdispatch names or style(9)? I would tend to assume = style(9) >=20 John Baldwin, George Neville-Neil, and I had a similar GCDish = conversation while I was in NYC over the weekend. I think this topic = calls for a detailed discussion at BSDCan -- there are a number of = complicating issues, not least that C Blocks (closures) require C = runtime changes and perform memory allocation. When I first got involved = in GCD, I commented to Apple that there are marked (but unsurprising) = similarities to existing concurrency frameworks we use in the kernel, = such as netisr/taskqueue/etc for asynchronous work scheduling. However, = the impact of features like Blocks shouldn't be underestimated: they = bring significant code simplicity and correctness benefits that are part = of what makes the GCD model work so well. I think for your immediate needs, a refinement of our notion of = taskqueue might be the best way forward, though, with a more general = discussion of the technologies and approaches in GCD at a later date. Robert=