From owner-freebsd-arch@FreeBSD.ORG Tue Nov 2 07:38:37 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 B4C79106564A; Tue, 2 Nov 2010 07:38:37 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe04.swip.net [212.247.154.97]) by mx1.freebsd.org (Postfix) with ESMTP id 816238FC18; Tue, 2 Nov 2010 07:38:35 +0000 (UTC) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.1 cv=gl0LPzB4YDQuuzpDoHYit7deEV0cOo++Sg28kyvF6vg= c=1 sm=1 a=FberXtVRn-wA:10 a=Q9fys5e9bTEA:10 a=CL8lFSKtTFcA:10 a=i9M/sDlu2rpZ9XS819oYzg==:17 a=WktskUVpHMbtOkM2tRUA:9 a=1nZNbYgAICjbbIhLnOsA:7 a=fXf6KUqNvkir4ELthc67aDRHUWIA:4 a=PUjeQqilurYA:10 a=QLp5_XDAv1VEkvBO:21 a=9dnm0tSLCu5UgOgx:21 a=i9M/sDlu2rpZ9XS819oYzg==:117 Received: from [188.126.198.129] (account mc467741@c2i.net HELO laptop002.hselasky.homeunix.org) by mailfe04.swip.net (CommuniGate Pro SMTP 5.2.19) with ESMTPA id 43160988; Tue, 02 Nov 2010 08:38:34 +0100 From: Hans Petter Selasky To: John Baldwin Date: Tue, 2 Nov 2010 08:39:45 +0100 User-Agent: KMail/1.13.5 (FreeBSD/8.1-STABLE; KDE/4.4.5; amd64; ; ) References: <201011012054.59551.hselasky@c2i.net> <201011011714.50121.jhb@freebsd.org> In-Reply-To: <201011011714.50121.jhb@freebsd.org> X-Face: +~\`s("[*|O,="7?X@L.elg*F"OA\I/3%^p8g?ab%RN'(; _IjlA: hGE..Ew, XAQ*o#\/M~SC=S1-f9{EzRfT'|Hhll5Q]ha5Bt-s|oTlKMusi:1e[wJl}kd}GR Z0adGx-x_0zGbZj'e(Y[(UNle~)8CQWXW@:DX+9)_YlB[tIccCPN$7/L' MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201011020839.45839.hselasky@c2i.net> Cc: freebsd-current@freebsd.org, Weongyo Jeong , freebsd-usb@freebsd.org, Andrew Thompson , freebsd-arch@freebsd.org Subject: Re: [RFC] Outline of USB process integration in the kernel taskqueue system 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: Tue, 02 Nov 2010 07:38:37 -0000 On Monday 01 November 2010 22:14:49 John Baldwin wrote: > On Monday, November 01, 2010 3:54:59 pm Hans Petter Selasky wrote: > > Hi! > > > > I've wrapped up an outline patch for what needs to be done to integrate > > the USB process framework into the kernel taskqueue system in a more > > direct way that to wrap it. > > > > The limitation of the existing taskqueue system is that it only > > guarantees execution at a given priority level. USB requires more. USB > > also requires a guarantee that the last task queued task also gets > > executed last. This is for example so that a deferred USB detach event > > does not happen before any pending deferred I/O for example in case of > > multiple occurring events. > > > > Mostly this new feature is targeted for GPIO-alike system using slow > > busses like the USB. Typical use case: > > > > 2 tasks to program GPIO on. > > 2 tasks to program GPIO off. > > > > Example: > > > > a) taskqueue_enqueue_odd(&sc->sc_taskqueue, &sc->sc_task_on[0], &sc- > > > > >sc_task_on[1]); > > > > b) taskqueue_enqueue_odd(&sc->sc_taskqueue, &sc->sc_task_off[0], &sc- > > > > >sc_task_off[1]); > > > > No matter how the call ordering of code-line a) and b), we are always > > guaranteed that the last queued state "on" or "off" is reached before the > > head of the taskqueue empties. > > > > > > In lack of a better name, the new function was called > > taskqueue_enqueue_odd [some people obviously think that USB processes > > are odd, but not taskqueues > > > > :-)] > > It feels like this should be something you could manage with a state > machine internal to USB rather than forcing that state into the taskqueue > code itself. Hi John, No, this is not possible without keeping my own queue, which I want to avoid. By state-machine you mean remembering the last state as a separate variable and checking that in the task-callback, right? Yes, I do that in addition to the new queuing mechanism. A task barrier does not solve my problem. The barrier in my case is always last in the queue. I need to pull out previously queued tasks and put them last. That is currently not supported. I do this because I don't want to have a FIFO signalling model, and a neither want the pure taskqueue, which only ensures execution, not order of execution when at the same priority. Another issue: Won't the barrier model lead to blocking the caller once the task in question is being issued the second time? --HPS > If you wanted a simple barrier task (where a barrier task is > always queued at the tail of the list and all subsequent tasks are queued > after the barrier task) then I would be fine with adding that. You could > manage this without having to alter the task KBI by having the taskqueue > maintain a separate pointer to the current "barrier" task and always > enqueue entries after that task (the barrier would be NULL before a > barrier is queued, and set to NULL when a barrier executes). > > I think this sort of semantic is a bit simpler and also used in other parts > of the tree (e.g. in bio queues).