From owner-freebsd-arch@FreeBSD.ORG Mon Nov 1 11:45:25 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 BD11D106564A for ; Mon, 1 Nov 2010 11:45:25 +0000 (UTC) (envelope-from etnapierala@googlemail.com) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 3F1A78FC17 for ; Mon, 1 Nov 2010 11:45:24 +0000 (UTC) Received: by wyb42 with SMTP id 42so5368296wyb.13 for ; Mon, 01 Nov 2010 04:45:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:sender:subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to:x-mailer; bh=h4QoQvbA3MDm/61qrt/efgrPYiYTG9Wbbr7fviP1E5Y=; b=PExlBLOnRjd9jNuhObx9lGUGxMM5j8cs3epZF3ees3892HYcTSfFPYrGb1FAP0XUgA 6fzupDjxjp8M6G0032UKUQbDINTw/vzudd0fSB+mRsCcfR7Tnr7ZP+fZ5BtVxKUQnwwK 7cws9JfNOmQsLc6Yk3fF6XoN0i3eb1SCtP4/I= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=ZWqVsTftK1/ZclniMt/vqVTW5mUuUFLxS862KNGHNjfSIxtLazC8vpgAjyiJEwAAU/ 1pU5XIGGUtOqmiLtHH1T13kXfoKLXAy/KwaKQIH5R5Sev8dqdlXbe/HqUYerYwShdGs/ LoFIAT/WgrzkJVUgDXkiSpmUxHb6q/E8/wdtI= Received: by 10.216.185.4 with SMTP id t4mr63425wem.87.1288611924247; Mon, 01 Nov 2010 04:45:24 -0700 (PDT) Received: from [192.168.2.7] (gate19.robnet.pl [194.105.132.219]) by mx.google.com with ESMTPS id x65sm3767606weq.25.2010.11.01.04.45.22 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 01 Nov 2010 04:45:22 -0700 (PDT) Sender: =?UTF-8?Q?Edward_Tomasz_Napiera=C5=82a?= Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=iso-8859-2 From: =?iso-8859-2?Q?Edward_Tomasz_Napiera=B3a?= In-Reply-To: <0C4615AC-7F1F-4486-A431-500535B79B2E@kientzle.com> Date: Mon, 1 Nov 2010 12:45:19 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <6C83B4B3-EE48-4344-8B8E-BED7FB5E9646@freebsd.org> References: <7CE78D72-F349-443B-A635-8DC7B970C2E0@freebsd.org> <0C4615AC-7F1F-4486-A431-500535B79B2E@kientzle.com> To: Tim Kientzle X-Mailer: Apple Mail (2.1081) Cc: "arch@" Subject: Re: Adapting FreeBSD to PSARC/2010/029. 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: Mon, 01 Nov 2010 11:45:25 -0000 Wiadomo=B6=E6 napisana przez Tim Kientzle w dniu 2010-10-30, o godz. = 07:17: > On Oct 29, 2010, at 11:44 AM, Edward Tomasz Napiera=B3a wrote: >> Currently, NFSv4 ACLs support in FreeBSD adheres to a draft by Sam = Falkner >> (it also complies with RFC3530, but that one leaves many things = undefined). >> Semantics for both UFS and ZFS is exactly the same. With ZFS v28, = the >> semantics has changed; see the link below for details: >>=20 >> = http://arc.opensolaris.org/caselog/PSARC/2010/029/20100126_mark.shellenbau= m >=20 > I guess I need to get back to work on the NFSv4 ACL support for = libarchive, eh? Obviously :-) > This is great. Together with the acl_is_trivial_np() test function, = the ACL > support now makes a lot more sense. >=20 > The chmod(2) interaction, in particular, is a huge improvement. I'm not sure about it. I mean, yes, it's simpler - it's actually = possible to understand and remember how it works now - but from what I remember, the problem with the old semantics and libarchive was that libarchive = tried to set file mode after restoring the ACL. With draft semantics, this resulted in malformed ACL. With PSARC semantics, this results in no ACL at all. -- If you cut off my head, what would I say? Me and my head, or me and my = body? From owner-freebsd-arch@FreeBSD.ORG Mon Nov 1 19:53:52 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 346EA106566C; Mon, 1 Nov 2010 19:53:52 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe06.swip.net [212.247.154.161]) by mx1.freebsd.org (Postfix) with ESMTP id E0B038FC19; Mon, 1 Nov 2010 19:53:50 +0000 (UTC) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.1 cv=5UXFHLfkiY5XrCDma5uYm2T9fyMGz6t0cyN4hLfZsqg= c=1 sm=1 a=ZJKxzO8xKrIA:10 a=CL8lFSKtTFcA:10 a=i9M/sDlu2rpZ9XS819oYzg==:17 a=oRQRuTlL4tF4YFdG0KEA:9 a=ObUINUouHsCKj4En9vAA:7 a=Fy61cc9Geugf3KA_8aKYKOD7WEoA:4 a=CjuIK1q_8ugA:10 a=Bv938iqYfvFtlDwxFssA:9 a=uM761qN_FhgtPHaD6xMA:7 a=J3rm2JEZ12vxksrYZHk5wOmsnpoA:4 a=2oojFnQ6c6Waurg1:21 a=ZqU7GHg2O_BuwJCW:21 a=i9M/sDlu2rpZ9XS819oYzg==:117 Received: from [188.126.198.129] (account mc467741@c2i.net HELO laptop002.hselasky.homeunix.org) by mailfe06.swip.net (CommuniGate Pro SMTP 5.2.19) with ESMTPA id 42649858; Mon, 01 Nov 2010 20:53:48 +0100 From: Hans Petter Selasky To: Andrew Thompson Date: Mon, 1 Nov 2010 20:54:59 +0100 User-Agent: KMail/1.13.5 (FreeBSD/8.1-STABLE; KDE/4.4.5; amd64; ; ) 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: Multipart/Mixed; boundary="Boundary-00=_TsxzMdRyDrUyIHv" Message-Id: <201011012054.59551.hselasky@c2i.net> Cc: freebsd-arch@freebsd.org, freebsd-usb@freebsd.org, freebsd-current@freebsd.org, Weongyo Jeong Subject: [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: Mon, 01 Nov 2010 19:53:52 -0000 --Boundary-00=_TsxzMdRyDrUyIHv Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: 7bit 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 :-)] Manpage: .Ft int .Fn taskqueue_enqueue_odd "struct taskqueue *queue" "struct task *t0" "struct task *t1" .. The function .Fn taskqueue_enqueue_odd should be used if it is important that the last queued task is also executed last in the task queue at the given priority level. This function requires two valid task pointers. Depending on which of the tasks passed are queued at the calling moment, the last queued task of the two will get dequeued and put last in the task queue, while not touching the first queued task. If no tasks are queued at the calling moment, this function behaves like .Fn taskqueue_enqueue . This function returns zero if the first task was queued last, one if the second task was queued last. Preliminary patch - see e-mail attachment. Comments are welcome! --HPS More docs: Also see talk about the new USB stack in FreeBSD on Youtube. --Boundary-00=_TsxzMdRyDrUyIHv Content-Type: text/plain; charset="us-ascii"; name="hps_taskqueue_patch_v001.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="hps_taskqueue_patch_v001.txt" === share/man/man9/taskqueue.9 ================================================================== --- share/man/man9/taskqueue.9 (revision 214211) +++ share/man/man9/taskqueue.9 (local) @@ -46,11 +46,15 @@ typedef void (*taskqueue_enqueue_fn)(void *context); struct task { - STAILQ_ENTRY(task) ta_link; /* link for queue */ - u_short ta_pending; /* count times queued */ - u_short ta_priority; /* priority of task in queue */ - task_fn_t ta_func; /* task handler */ - void *ta_context; /* argument for handler */ + TAILQ_ENTRY(task) ta_link; /* link for queue */ +#define TASKQUEUE_SEQUENCE_MAX 255 + u_char ta_sequence; /* sequence number */ +#define TASKQUEUE_PENDING_MAX 255 + u_char ta_pending; /* count times queued */ +#define TASKQUEUE_PRIORITY_MAX 65535U + u_short ta_priority; /* priority of task in queue */ + task_fn_t *ta_func; /* task handler */ + void *ta_context; /* argument for handler */ }; .Ed .Ft struct taskqueue * @@ -62,6 +66,8 @@ .Ft int .Fn taskqueue_enqueue "struct taskqueue *queue" "struct task *task" .Ft int +.Fn taskqueue_enqueue_odd "struct taskqueue *queue" "struct task *t0" "struct task *t1" +.Ft int .Fn taskqueue_enqueue_fast "struct taskqueue *queue" "struct task *task" .Ft void .Fn taskqueue_drain "struct taskqueue *queue" "struct task *task" @@ -134,6 +140,19 @@ if the queue is being freed. .Pp The function +.Fn taskqueue_enqueue_odd +should be used if it is important that the last queued task is also +executed last in the task queue at the given priority level. This +function requires two valid task pointers. Depending on which of the +tasks passed are queued at the calling moment, the last queued task of +the two will get dequeued and put last in the task queue, while not +touching the first queued task. If no tasks are queued at the calling +moment, this function behaves like +.Fn taskqueue_enqueue . +This function returns zero if the first task was queued last, one if +the second task was queued last. +.Pp +The function .Fn taskqueue_enqueue_fast should be used in place of .Fn taskqueue_enqueue === sys/sys/_task.h ================================================================== --- sys/sys/_task.h (revision 214433) +++ sys/sys/_task.h (local) @@ -44,9 +44,13 @@ typedef void task_fn_t(void *context, int pending); struct task { - STAILQ_ENTRY(task) ta_link; /* (q) link for queue */ - u_short ta_pending; /* (q) count times queued */ - u_short ta_priority; /* (c) Priority */ + TAILQ_ENTRY(task) ta_link; /* (q) link for queue */ +#define TASKQUEUE_SEQUENCE_MAX 255U + u_char ta_sequence; /* (q) sequence number */ +#define TASKQUEUE_PENDING_MAX 255U + u_char ta_pending; /* (q) count times queued */ +#define TASKQUEUE_PRIORITY_MAX 65535U + u_short ta_priority; /* (c) priority of task in queue */ task_fn_t *ta_func; /* (c) task handler */ void *ta_context; /* (c) argument for handler */ }; === sys/sys/taskqueue.h ================================================================== --- sys/sys/taskqueue.h (revision 214433) +++ sys/sys/taskqueue.h (local) @@ -54,6 +54,7 @@ int taskqueue_start_threads(struct taskqueue **tqp, int count, int pri, const char *name, ...) __printflike(4, 5); int taskqueue_enqueue(struct taskqueue *queue, struct task *task); +int taskqueue_enqueue_odd(struct taskqueue *queue, struct task *t0, struct task *t1); void taskqueue_drain(struct taskqueue *queue, struct task *task); void taskqueue_free(struct taskqueue *queue); void taskqueue_run(struct taskqueue *queue); @@ -71,6 +72,7 @@ * Initialise a task structure. */ #define TASK_INIT(task, priority, func, context) do { \ + (task)->ta_link.tqe_prev = NULL; \ (task)->ta_pending = 0; \ (task)->ta_priority = (priority); \ (task)->ta_func = (func); \ === sys/kern/subr_taskqueue.c ================================================================== --- sys/kern/subr_taskqueue.c (revision 214433) +++ sys/kern/subr_taskqueue.c (local) @@ -52,7 +52,7 @@ }; struct taskqueue { - STAILQ_HEAD(, task) tq_queue; + TAILQ_HEAD(task_head, task) tq_queue; const char *tq_name; taskqueue_enqueue_fn tq_enqueue; void *tq_context; @@ -62,12 +62,15 @@ int tq_tcount; int tq_spin; int tq_flags; + u_char tq_sequence; }; #define TQ_FLAGS_ACTIVE (1 << 0) #define TQ_FLAGS_BLOCKED (1 << 1) #define TQ_FLAGS_PENDING (1 << 2) +static void taskqueue_enqueue_locked(struct taskqueue *, struct task *); + static __inline void TQ_LOCK(struct taskqueue *tq) { @@ -106,7 +109,7 @@ if (!queue) return NULL; - STAILQ_INIT(&queue->tq_queue); + TAILQ_INIT(&queue->tq_queue); TAILQ_INIT(&queue->tq_active); queue->tq_name = name; queue->tq_enqueue = enqueue; @@ -155,48 +158,132 @@ int taskqueue_enqueue(struct taskqueue *queue, struct task *task) { - struct task *ins; - struct task *prev; - TQ_LOCK(queue); /* * Count multiple enqueues. */ if (task->ta_pending) { - task->ta_pending++; + if (task->ta_pending != TASKQUEUE_PENDING_MAX) + task->ta_pending++; TQ_UNLOCK(queue); - return 0; + return (0); } + KASSERT(task->ta_link.tqe_prev == NULL, ("Task already queued?")); + + /* Insert task in queue */ + + taskqueue_enqueue_locked(queue, task); + + TQ_UNLOCK(queue); + + return (0); +} + +/* Enqueue task ordered and dualed */ + +int +taskqueue_enqueue_odd(struct taskqueue *queue, struct task *t0, struct task *t1) +{ + struct task *tx; + uint8_t t; + uint8_t d; + + TQ_LOCK(queue); + /* + * Compute a number based on which of the two tasks passed as + * arguments to this function are queued. + */ + t = 0; + if (t0->ta_link.tqe_prev != NULL) + t |= 1; + if (t1->ta_link.tqe_prev != NULL) + t |= 2; + + if (t == 0) { + /* + * No entries are queued. Queue task "t0" last and use + * the existing sequence number. + */ + tx = t0; + } else if (t == 1) { + /* + * Check if we need to increment the sequence number. + */ + if (t0->ta_sequence == queue->tq_sequence) + queue->tq_sequence++; + + tx = t1; + } else if (t == 2) { + /* + * Check if we need to increment the sequence number. + */ + if (t1->ta_sequence == queue->tq_sequence) + queue->tq_sequence++; + + tx = t0; + } else { + /* + * Both tasks are queued. Re-queue the task closest to + * the end which is computed by looking at the + * sequence number. + */ + d = (t1->ta_sequence - t0->ta_sequence); + + /* Check sign after subtraction */ + if (d & 0x80) + tx = t0; + else + tx = t1; + + TAILQ_REMOVE(&queue->tq_queue, tx, ta_link); + } + + /* Insert task in queue */ + + taskqueue_enqueue_locked(queue, tx); + + TQ_UNLOCK(queue); + + if (tx == t1) + return (1); + + return (0); +} + +static void +taskqueue_enqueue_locked(struct taskqueue *queue, struct task *task) +{ + struct task *ins; + struct task *prev; + + /* * Optimise the case when all tasks have the same priority. */ - prev = STAILQ_LAST(&queue->tq_queue, task, ta_link); + prev = TAILQ_LAST(&queue->tq_queue, task_head); if (!prev || prev->ta_priority >= task->ta_priority) { - STAILQ_INSERT_TAIL(&queue->tq_queue, task, ta_link); + TAILQ_INSERT_TAIL(&queue->tq_queue, task, ta_link); } else { prev = NULL; - for (ins = STAILQ_FIRST(&queue->tq_queue); ins; - prev = ins, ins = STAILQ_NEXT(ins, ta_link)) + for (ins = TAILQ_FIRST(&queue->tq_queue); ins; + prev = ins, ins = TAILQ_NEXT(ins, ta_link)) if (ins->ta_priority < task->ta_priority) break; if (prev) - STAILQ_INSERT_AFTER(&queue->tq_queue, prev, task, ta_link); + TAILQ_INSERT_AFTER(&queue->tq_queue, prev, task, ta_link); else - STAILQ_INSERT_HEAD(&queue->tq_queue, task, ta_link); + TAILQ_INSERT_HEAD(&queue->tq_queue, task, ta_link); } + task->ta_sequence = queue->tq_sequence; task->ta_pending = 1; if ((queue->tq_flags & TQ_FLAGS_BLOCKED) == 0) queue->tq_enqueue(queue->tq_context); else queue->tq_flags |= TQ_FLAGS_PENDING; - - TQ_UNLOCK(queue); - - return 0; } void @@ -232,13 +319,14 @@ tb.tb_running = NULL; TAILQ_INSERT_TAIL(&queue->tq_active, &tb, tb_link); - while (STAILQ_FIRST(&queue->tq_queue)) { + while ((task = TAILQ_FIRST(&queue->tq_queue)) != NULL) { /* - * Carefully remove the first task from the queue and - * zero its pending count. + * Carefully remove the first task from the queue, + * clear the previous next pointer and zero its + * pending count. */ - task = STAILQ_FIRST(&queue->tq_queue); - STAILQ_REMOVE_HEAD(&queue->tq_queue, ta_link); + TAILQ_REMOVE(&queue->tq_queue, task, ta_link); + task->ta_link.tqe_prev = NULL; pending = task->ta_pending; task->ta_pending = 0; tb.tb_running = task; --Boundary-00=_TsxzMdRyDrUyIHv-- From owner-freebsd-arch@FreeBSD.ORG Mon Nov 1 20:07:30 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 DF95E106566B; Mon, 1 Nov 2010 20:07:30 +0000 (UTC) (envelope-from mdf356@gmail.com) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 79EEC8FC1A; Mon, 1 Nov 2010 20:07:30 +0000 (UTC) Received: by iwn39 with SMTP id 39so7465195iwn.13 for ; Mon, 01 Nov 2010 13:07:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=RWRcEYFem6yf3fFJORN9++0ZAcVpKD8bEdU3c+Br+K0=; b=nYzGF19PZHbdY+6HSGUtgeRe15B//XOSLLcRdlApiCEsfJDl804+TwBLyLFdoS3565 bIr7IkDd6DL6e6Y23BDHqLfx6hclDaqfm8mAQKsod3osYKL2lsfipRU+antc2F23hu5U JvVUWLMMAjFiHE6vZtY1BCaXoq5t1ZlFuJx0Y= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=FgzmYJefrCOF1QzDICxSxu1Ir7bgCDwQO1m0ULj6dYR3JNFbNqr+3mcKzt/01yg6Ch xi6P56kzYuLvAR5VkxZXSdd69O4odBl5dQnRpwfrr88GJcxZs1CjtYZdz/eN39tOlom5 8W+2qmZrQ8mgws3IO4FHcDHwMuhVEU756za4k= MIME-Version: 1.0 Received: by 10.231.36.11 with SMTP id r11mr3331721ibd.58.1288642049448; Mon, 01 Nov 2010 13:07:29 -0700 (PDT) Received: by 10.231.159.198 with HTTP; Mon, 1 Nov 2010 13:07:29 -0700 (PDT) In-Reply-To: <201011012054.59551.hselasky@c2i.net> References: <201011012054.59551.hselasky@c2i.net> Date: Mon, 1 Nov 2010 13:07:29 -0700 Message-ID: From: Matthew Fleming To: Hans Petter Selasky Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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: Mon, 01 Nov 2010 20:07:31 -0000 On Mon, Nov 1, 2010 at 12:54 PM, Hans Petter Selasky wro= te: > Hi! > > I've wrapped up an outline patch for what needs to be done to integrate t= he > USB process framework into the kernel taskqueue system in a more direct w= ay > that to wrap it. > > The limitation of the existing taskqueue system is that it only guarantee= s > 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 pe= nding > deferred I/O for example in case of multiple occurring events. > > Mostly this new feature is targeted for GPIO-alike system using slow buss= es > 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_o= dd > [some people obviously think that USB processes are odd, but not taskqueu= es > :-)] I'd like to make sure I understand the USB requirements. (1) does USB need the task priority field? Many taskqueue(9) consumers do = not. (2) if there was a working taskqueue_remove(9) that removed the task if pending or returned error if the task was currently running, would that be sufficient to implement the required USB functionality? (assuming that taskqueue_enqueue(9) put all tasks with equal priority in order of queueing). Thanks, matthew > Manpage: > > .Ft int > .Fn taskqueue_enqueue_odd "struct taskqueue *queue" "struct task *t0" "st= ruct > task *t1" > > .. > > The function > .Fn taskqueue_enqueue_odd > should be used if it is important that the last queued task is also > executed last in the task queue at the given priority level. This > function requires two valid task pointers. Depending on which of the > tasks passed are queued at the calling moment, the last queued task of > the two will get dequeued and put last in the task queue, while not > touching the first queued task. If no tasks are queued at the calling > moment, this function behaves like > .Fn taskqueue_enqueue . > This function returns zero if the first task was queued last, one if > the second task was queued last. > > Preliminary patch - see e-mail attachment. > > Comments are welcome! > > --HPS > > More docs: Also see talk about the new USB stack in FreeBSD on Youtube. > > =3D=3D=3D share/man/man9/taskqueue.9 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- share/man/man9/taskqueue.9 =A0(revision 214211) > +++ share/man/man9/taskqueue.9 =A0(local) > @@ -46,11 +46,15 @@ > =A0typedef void (*taskqueue_enqueue_fn)(void *context); > > =A0struct task { > - =A0 =A0 =A0 STAILQ_ENTRY(task) =A0 =A0 =A0ta_link; =A0 =A0 =A0 =A0/* li= nk for queue */ > - =A0 =A0 =A0 u_short =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ta_pending; =A0 =A0= /* count times queued */ > - =A0 =A0 =A0 u_short =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ta_priority; =A0 = =A0/* priority of task in queue */ > - =A0 =A0 =A0 task_fn_t =A0 =A0 =A0 =A0 =A0 =A0 =A0 ta_func; =A0 =A0 =A0 = =A0/* task handler */ > - =A0 =A0 =A0 void =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0*ta_context; = =A0 =A0/* argument for handler */ > + =A0 =A0 =A0 TAILQ_ENTRY(task) ta_link; =A0 =A0 =A0/* link for queue */ > +#define =A0 =A0 =A0 =A0TASKQUEUE_SEQUENCE_MAX =A0255 > + =A0 =A0 =A0 u_char =A0ta_sequence; =A0 =A0 =A0 =A0 =A0 =A0/* sequence n= umber */ > +#define =A0 =A0 =A0 =A0TASKQUEUE_PENDING_MAX =A0 255 > + =A0 =A0 =A0 u_char =A0ta_pending; =A0 =A0 =A0 =A0 =A0 =A0 /* count time= s queued */ > +#define =A0 =A0 =A0 =A0TASKQUEUE_PRIORITY_MAX =A065535U > + =A0 =A0 =A0 u_short ta_priority; =A0 =A0 =A0 =A0 =A0 =A0/* priority of = task in queue */ > + =A0 =A0 =A0 task_fn_t *ta_func; =A0 =A0 =A0 =A0 =A0 =A0 /* task handler= */ > + =A0 =A0 =A0 void =A0 =A0*ta_context; =A0 =A0 =A0 =A0 =A0 =A0/* argument= for handler */ > =A0}; > =A0.Ed > =A0.Ft struct taskqueue * > @@ -62,6 +66,8 @@ > =A0.Ft int > =A0.Fn taskqueue_enqueue "struct taskqueue *queue" "struct task *task" > =A0.Ft int > +.Fn taskqueue_enqueue_odd "struct taskqueue *queue" "struct task *t0" "s= truct task *t1" > +.Ft int > =A0.Fn taskqueue_enqueue_fast "struct taskqueue *queue" "struct task *tas= k" > =A0.Ft void > =A0.Fn taskqueue_drain "struct taskqueue *queue" "struct task *task" > @@ -134,6 +140,19 @@ > =A0if the queue is being freed. > =A0.Pp > =A0The function > +.Fn taskqueue_enqueue_odd > +should be used if it is important that the last queued task is also > +executed last in the task queue at the given priority level. This > +function requires two valid task pointers. Depending on which of the > +tasks passed are queued at the calling moment, the last queued task of > +the two will get dequeued and put last in the task queue, while not > +touching the first queued task. If no tasks are queued at the calling > +moment, this function behaves like > +.Fn taskqueue_enqueue . > +This function returns zero if the first task was queued last, one if > +the second task was queued last. > +.Pp > +The function > =A0.Fn taskqueue_enqueue_fast > =A0should be used in place of > =A0.Fn taskqueue_enqueue > =3D=3D=3D sys/sys/_task.h > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- sys/sys/_task.h =A0 =A0 (revision 214433) > +++ sys/sys/_task.h =A0 =A0 (local) > @@ -44,9 +44,13 @@ > =A0typedef void task_fn_t(void *context, int pending); > > =A0struct task { > - =A0 =A0 =A0 STAILQ_ENTRY(task) ta_link; =A0 =A0 /* (q) link for queue *= / > - =A0 =A0 =A0 u_short ta_pending; =A0 =A0 =A0 =A0 =A0 =A0 /* (q) count ti= mes queued */ > - =A0 =A0 =A0 u_short ta_priority; =A0 =A0 =A0 =A0 =A0 =A0/* (c) Priority= */ > + =A0 =A0 =A0 TAILQ_ENTRY(task) ta_link; =A0 =A0 =A0/* (q) link for queue= */ > +#define =A0 =A0 =A0 =A0TASKQUEUE_SEQUENCE_MAX =A0255U > + =A0 =A0 =A0 u_char =A0ta_sequence; =A0 =A0 =A0 =A0 =A0 =A0/* (q) sequen= ce number */ > +#define =A0 =A0 =A0 =A0TASKQUEUE_PENDING_MAX =A0 255U > + =A0 =A0 =A0 u_char =A0ta_pending; =A0 =A0 =A0 =A0 =A0 =A0 /* (q) count = times queued */ > +#define =A0 =A0 =A0 =A0TASKQUEUE_PRIORITY_MAX =A065535U > + =A0 =A0 =A0 u_short ta_priority; =A0 =A0 =A0 =A0 =A0 =A0/* (c) priority= of task in queue */ > =A0 =A0 =A0 =A0task_fn_t *ta_func; =A0 =A0 =A0 =A0 =A0 =A0 /* (c) task ha= ndler */ > =A0 =A0 =A0 =A0void =A0 =A0*ta_context; =A0 =A0 =A0 =A0 =A0 =A0/* (c) arg= ument for handler */ > =A0}; > =3D=3D=3D sys/sys/taskqueue.h > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- sys/sys/taskqueue.h (revision 214433) > +++ sys/sys/taskqueue.h (local) > @@ -54,6 +54,7 @@ > =A0int =A0 =A0taskqueue_start_threads(struct taskqueue **tqp, int count, = int pri, > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0const char= *name, ...) __printflike(4, 5); > =A0int =A0 =A0taskqueue_enqueue(struct taskqueue *queue, struct task *tas= k); > +int =A0 =A0taskqueue_enqueue_odd(struct taskqueue *queue, struct task *t= 0, struct task *t1); > =A0void =A0 taskqueue_drain(struct taskqueue *queue, struct task *task); > =A0void =A0 taskqueue_free(struct taskqueue *queue); > =A0void =A0 taskqueue_run(struct taskqueue *queue); > @@ -71,6 +72,7 @@ > =A0* Initialise a task structure. > =A0*/ > =A0#define TASK_INIT(task, priority, func, context) do { =A0\ > + =A0 =A0 =A0 (task)->ta_link.tqe_prev =3D NULL; =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0\ > =A0 =A0 =A0 =A0(task)->ta_pending =3D 0; =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 \ > =A0 =A0 =A0 =A0(task)->ta_priority =3D (priority); =A0 =A0 =A0 =A0 =A0 = =A0 =A0 \ > =A0 =A0 =A0 =A0(task)->ta_func =3D (func); =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 \ > =3D=3D=3D sys/kern/subr_taskqueue.c > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- sys/kern/subr_taskqueue.c =A0 (revision 214433) > +++ sys/kern/subr_taskqueue.c =A0 (local) > @@ -52,7 +52,7 @@ > =A0}; > > =A0struct taskqueue { > - =A0 =A0 =A0 STAILQ_HEAD(, task) =A0 =A0 tq_queue; > + =A0 =A0 =A0 TAILQ_HEAD(task_head, task) =A0 =A0 tq_queue; > =A0 =A0 =A0 =A0const char =A0 =A0 =A0 =A0 =A0 =A0 =A0*tq_name; > =A0 =A0 =A0 =A0taskqueue_enqueue_fn =A0 =A0tq_enqueue; > =A0 =A0 =A0 =A0void =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0*tq_context; > @@ -62,12 +62,15 @@ > =A0 =A0 =A0 =A0int =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 tq_tcount; > =A0 =A0 =A0 =A0int =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 tq_spin; > =A0 =A0 =A0 =A0int =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 tq_flags; > + =A0 =A0 =A0 u_char =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0tq_sequence; > =A0}; > > =A0#define =A0 =A0 =A0 =A0TQ_FLAGS_ACTIVE =A0 =A0 =A0 =A0 (1 << 0) > =A0#define =A0 =A0 =A0 =A0TQ_FLAGS_BLOCKED =A0 =A0 =A0 =A0(1 << 1) > =A0#define =A0 =A0 =A0 =A0TQ_FLAGS_PENDING =A0 =A0 =A0 =A0(1 << 2) > > +static void taskqueue_enqueue_locked(struct taskqueue *, struct task *); > + > =A0static __inline void > =A0TQ_LOCK(struct taskqueue *tq) > =A0{ > @@ -106,7 +109,7 @@ > =A0 =A0 =A0 =A0if (!queue) > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0return NULL; > > - =A0 =A0 =A0 STAILQ_INIT(&queue->tq_queue); > + =A0 =A0 =A0 TAILQ_INIT(&queue->tq_queue); > =A0 =A0 =A0 =A0TAILQ_INIT(&queue->tq_active); > =A0 =A0 =A0 =A0queue->tq_name =3D name; > =A0 =A0 =A0 =A0queue->tq_enqueue =3D enqueue; > @@ -155,48 +158,132 @@ > =A0int > =A0taskqueue_enqueue(struct taskqueue *queue, struct task *task) > =A0{ > - =A0 =A0 =A0 struct task *ins; > - =A0 =A0 =A0 struct task *prev; > - > =A0 =A0 =A0 =A0TQ_LOCK(queue); > > =A0 =A0 =A0 =A0/* > =A0 =A0 =A0 =A0 * Count multiple enqueues. > =A0 =A0 =A0 =A0 */ > =A0 =A0 =A0 =A0if (task->ta_pending) { > - =A0 =A0 =A0 =A0 =A0 =A0 =A0 task->ta_pending++; > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 if (task->ta_pending !=3D TASKQUEUE_PENDING= _MAX) > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 task->ta_pending++; > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0TQ_UNLOCK(queue); > - =A0 =A0 =A0 =A0 =A0 =A0 =A0 return 0; > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 return (0); > =A0 =A0 =A0 =A0} > > + =A0 =A0 =A0 KASSERT(task->ta_link.tqe_prev =3D=3D NULL, ("Task already = queued?")); > + > + =A0 =A0 =A0 /* Insert task in queue */ > + > + =A0 =A0 =A0 taskqueue_enqueue_locked(queue, task); > + > + =A0 =A0 =A0 TQ_UNLOCK(queue); > + > + =A0 =A0 =A0 return (0); > +} > + > +/* Enqueue task ordered and dualed */ > + > +int > +taskqueue_enqueue_odd(struct taskqueue *queue, struct task *t0, struct t= ask *t1) > +{ > + =A0 =A0 =A0 struct task *tx; > + =A0 =A0 =A0 uint8_t t; > + =A0 =A0 =A0 uint8_t d; > + > + =A0 =A0 =A0 TQ_LOCK(queue); > + > =A0 =A0 =A0 =A0/* > + =A0 =A0 =A0 =A0* Compute a number based on which of the two tasks passe= d as > + =A0 =A0 =A0 =A0* arguments to this function are queued. > + =A0 =A0 =A0 =A0*/ > + =A0 =A0 =A0 t =3D 0; > + =A0 =A0 =A0 if (t0->ta_link.tqe_prev !=3D NULL) > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 t |=3D 1; > + =A0 =A0 =A0 if (t1->ta_link.tqe_prev !=3D NULL) > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 t |=3D 2; > + > + =A0 =A0 =A0 if (t =3D=3D 0) { > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 /* > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0* No entries are queued. Queue task "t0"= last and use > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0* the existing sequence number. > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0*/ > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 tx =3D t0; > + =A0 =A0 =A0 } else if (t =3D=3D 1) { > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 /* > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0* Check if we need to increment the sequ= ence number. > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0*/ > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 if (t0->ta_sequence =3D=3D queue->tq_sequen= ce) > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 queue->tq_sequence++; > + > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 tx =3D t1; > + =A0 =A0 =A0 } else if (t =3D=3D 2) { > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 /* > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0* Check if we need to increment the sequ= ence number. > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0*/ > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 if (t1->ta_sequence =3D=3D queue->tq_sequen= ce) > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 queue->tq_sequence++; > + > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 tx =3D t0; > + =A0 =A0 =A0 } else { > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 /* > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0* Both tasks are queued. Re-queue the ta= sk closest to > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0* the end which is computed by looking a= t the > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0* sequence number. > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0*/ > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 d =3D (t1->ta_sequence - t0->ta_sequence); > + > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 /* Check sign after subtraction */ > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 if (d & 0x80) > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 tx =3D t0; > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 else > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 tx =3D t1; > + > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 TAILQ_REMOVE(&queue->tq_queue, tx, ta_link)= ; > + =A0 =A0 =A0 } > + > + =A0 =A0 =A0 /* Insert task in queue */ > + > + =A0 =A0 =A0 taskqueue_enqueue_locked(queue, tx); > + > + =A0 =A0 =A0 TQ_UNLOCK(queue); > + > + =A0 =A0 =A0 if (tx =3D=3D t1) > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 return (1); > + > + =A0 =A0 =A0 return (0); > +} > + > +static void > +taskqueue_enqueue_locked(struct taskqueue *queue, struct task *task) > +{ > + =A0 =A0 =A0 struct task *ins; > + =A0 =A0 =A0 struct task *prev; > + > + =A0 =A0 =A0 /* > =A0 =A0 =A0 =A0 * Optimise the case when all tasks have the same priority= . > =A0 =A0 =A0 =A0 */ > - =A0 =A0 =A0 prev =3D STAILQ_LAST(&queue->tq_queue, task, ta_link); > + =A0 =A0 =A0 prev =3D TAILQ_LAST(&queue->tq_queue, task_head); > =A0 =A0 =A0 =A0if (!prev || prev->ta_priority >=3D task->ta_priority) { > - =A0 =A0 =A0 =A0 =A0 =A0 =A0 STAILQ_INSERT_TAIL(&queue->tq_queue, task, = ta_link); > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 TAILQ_INSERT_TAIL(&queue->tq_queue, task, t= a_link); > =A0 =A0 =A0 =A0} else { > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0prev =3D NULL; > - =A0 =A0 =A0 =A0 =A0 =A0 =A0 for (ins =3D STAILQ_FIRST(&queue->tq_queue)= ; ins; > - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0prev =3D ins, ins =3D STAILQ_NEX= T(ins, ta_link)) > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 for (ins =3D TAILQ_FIRST(&queue->tq_queue);= ins; > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0prev =3D ins, ins =3D TAILQ_NEXT= (ins, ta_link)) > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0if (ins->ta_priority < tas= k->ta_priority) > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0break; > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0if (prev) > - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 STAILQ_INSERT_AFTER(&queue-= >tq_queue, prev, task, ta_link); > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 TAILQ_INSERT_AFTER(&queue->= tq_queue, prev, task, ta_link); > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0else > - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 STAILQ_INSERT_HEAD(&queue->= tq_queue, task, ta_link); > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 TAILQ_INSERT_HEAD(&queue->t= q_queue, task, ta_link); > =A0 =A0 =A0 =A0} > > + =A0 =A0 =A0 task->ta_sequence =3D queue->tq_sequence; > =A0 =A0 =A0 =A0task->ta_pending =3D 1; > =A0 =A0 =A0 =A0if ((queue->tq_flags & TQ_FLAGS_BLOCKED) =3D=3D 0) > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0queue->tq_enqueue(queue->tq_context); > =A0 =A0 =A0 =A0else > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0queue->tq_flags |=3D TQ_FLAGS_PENDING; > - > - =A0 =A0 =A0 TQ_UNLOCK(queue); > - > - =A0 =A0 =A0 return 0; > =A0} > > =A0void > @@ -232,13 +319,14 @@ > =A0 =A0 =A0 =A0tb.tb_running =3D NULL; > =A0 =A0 =A0 =A0TAILQ_INSERT_TAIL(&queue->tq_active, &tb, tb_link); > > - =A0 =A0 =A0 while (STAILQ_FIRST(&queue->tq_queue)) { > + =A0 =A0 =A0 while ((task =3D TAILQ_FIRST(&queue->tq_queue)) !=3D NULL) = { > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0/* > - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0* Carefully remove the first task from t= he queue and > - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0* zero its pending count. > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0* Carefully remove the first task from t= he queue, > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0* clear the previous next pointer and ze= ro its > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0* pending count. > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 */ > - =A0 =A0 =A0 =A0 =A0 =A0 =A0 task =3D STAILQ_FIRST(&queue->tq_queue); > - =A0 =A0 =A0 =A0 =A0 =A0 =A0 STAILQ_REMOVE_HEAD(&queue->tq_queue, ta_lin= k); > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 TAILQ_REMOVE(&queue->tq_queue, task, ta_lin= k); > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 task->ta_link.tqe_prev =3D NULL; > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0pending =3D task->ta_pending; > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0task->ta_pending =3D 0; > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0tb.tb_running =3D task; > > _______________________________________________ > freebsd-arch@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" > From owner-freebsd-arch@FreeBSD.ORG Mon Nov 1 20:14:06 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 9D296106564A; Mon, 1 Nov 2010 20:14:06 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe06.swip.net [212.247.154.161]) by mx1.freebsd.org (Postfix) with ESMTP id 7AA7F8FC1F; Mon, 1 Nov 2010 20:14:05 +0000 (UTC) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.1 cv=5UXFHLfkiY5XrCDma5uYm2T9fyMGz6t0cyN4hLfZsqg= c=1 sm=1 a=FberXtVRn-wA:10 a=8nJEP1OIZ-IA:10 a=CL8lFSKtTFcA:10 a=i9M/sDlu2rpZ9XS819oYzg==:17 a=8kQB0OdkAAAA:8 a=fSevNTtoN4QgcqRp2OYA:9 a=stlMNjSOas5fGyG6P3UA:7 a=6G91sS9h5Cx9rxYMxB0z_FDb4doA:4 a=wPNLvfGTeEIA:10 a=9aOQ2cSd83gA:10 a=i9M/sDlu2rpZ9XS819oYzg==:117 Received: from [188.126.198.129] (account mc467741@c2i.net HELO laptop002.hselasky.homeunix.org) by mailfe06.swip.net (CommuniGate Pro SMTP 5.2.19) with ESMTPA id 42657199; Mon, 01 Nov 2010 21:14:04 +0100 From: Hans Petter Selasky To: Matthew Fleming Date: Mon, 1 Nov 2010 21:15:15 +0100 User-Agent: KMail/1.13.5 (FreeBSD/8.1-STABLE; KDE/4.4.5; amd64; ; ) References: <201011012054.59551.hselasky@c2i.net> In-Reply-To: X-Face: +~\`s("[*|O,="7?X@L.elg*F"OA\I/3%^p8g?ab%RN'( =?iso-8859-1?q?=3B=5FIjlA=3A=0A=09hGE=2E=2EEw?=, =?iso-8859-1?q?XAQ*o=23=5C/M=7ESC=3DS1-f9=7BEzRfT=27=7CHhll5Q=5Dha5Bt-s=7Co?= =?iso-8859-1?q?TlKMusi=3A1e=5BwJl=7Dkd=7DGR=0A=09Z0adGx-x=5F0zGbZj=27e?=(Y[(UNle~)8CQWXW@:DX+9)_YlB[tIccCPN$7/L' MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201011012115.15261.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: Mon, 01 Nov 2010 20:14:06 -0000 On Monday 01 November 2010 21:07:29 Matthew Fleming wrote: > On Mon, Nov 1, 2010 at 12:54 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 > > > > :-)] > > I'd like to make sure I understand the USB requirements. > > (1) does USB need the task priority field? Many taskqueue(9) consumers do > not. No, USB does not need a task priority field, but a sequence field associated with the task and task queue head to figure out which task was queued first without having to scan all the tasks queued. > (2) if there was a working taskqueue_remove(9) that removed the task > if pending or returned error if the task was currently running, would > that be sufficient to implement the required USB functionality? > (assuming that taskqueue_enqueue(9) put all tasks with equal priority > in order of queueing). No, not completely. See comment above. I also need information about which task was queued first, or else I have to keep this information separately, which again, confuse people. The more layers the more confusion? --HPS From owner-freebsd-arch@FreeBSD.ORG Mon Nov 1 21:25:41 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 823C61065673; Mon, 1 Nov 2010 21:25:41 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 4E99E8FC13; Mon, 1 Nov 2010 21:25:41 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id D174246B85; Mon, 1 Nov 2010 17:25:40 -0400 (EDT) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id B40998A009; Mon, 1 Nov 2010 17:25:35 -0400 (EDT) From: John Baldwin To: freebsd-arch@freebsd.org Date: Mon, 1 Nov 2010 17:14:49 -0400 User-Agent: KMail/1.13.5 (FreeBSD/7.3-CBSD-20100819; KDE/4.4.5; amd64; ; ) References: <201011012054.59551.hselasky@c2i.net> In-Reply-To: <201011012054.59551.hselasky@c2i.net> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201011011714.50121.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Mon, 01 Nov 2010 17:25:35 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.96.3 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-1.9 required=4.2 tests=BAYES_00 autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on bigwig.baldwin.cx Cc: freebsd-current@freebsd.org, Weongyo Jeong , freebsd-usb@freebsd.org, Andrew Thompson , Hans Petter Selasky 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: Mon, 01 Nov 2010 21:25:41 -0000 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. 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). -- John Baldwin From owner-freebsd-arch@FreeBSD.ORG Tue Nov 2 02:28:45 2010 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CBF89106566B; Tue, 2 Nov 2010 02:28:45 +0000 (UTC) (envelope-from gnn@freebsd.org) Received: from vps.hungerhost.com (vps.hungerhost.com [216.38.53.176]) by mx1.freebsd.org (Postfix) with ESMTP id 9B2078FC0A; Tue, 2 Nov 2010 02:28:45 +0000 (UTC) Received: from smtp.hudson-trading.com ([209.249.190.9] helo=gnnmac.hudson-trading.com) by vps.hungerhost.com with esmtpa (Exim 4.69) (envelope-from ) id 1PCzvz-0007yN-Ie; Mon, 01 Nov 2010 15:20:50 -0400 From: George Neville-Neil Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Mon, 1 Nov 2010 15:20:46 -0400 Message-Id: <8C96F018-EA61-4C38-AC9A-148D1DC06193@freebsd.org> To: arch@freebsd.org Mime-Version: 1.0 (Apple Message framework v1081) X-Mailer: Apple Mail (2.1081) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - vps.hungerhost.com X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - freebsd.org X-Source: X-Source-Args: X-Source-Dir: Cc: net@freebsd.org Subject: RFC: Updated ARP Queue patch... 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 02:28:45 -0000 Howdy, This is marked as "Updated" because I first proposed this on arch@ but = am now sending it to a wider audience as I'm hoping to commit it in the near future. Please review the following patch against HEAD: http://people.freebsd.org/~gnn/head-arpqueue2.diff This patch makes two changes to the ARP code: 1) It adds a sysctl configurable queue of packets that are held until an = ARP reply is received or timed out. net.link.ether.inet.maxhold Having the queue addresses a problem in modern systems where programs = that use connectionless=20 protocols for communication will suffer from dropping many packets when = they start up or when an ARP entry moves. 2) Makes the time we wait for an arp reply configurable via another = sysctl. net.link.ether.inet.wait The old, pre 8.0, ARP code would run the timer once per second. The new ARP code sets a timeout of 20 seconds on each entry. Neither value was = specified in RFC 826. As a matter of fact, RFC 826 had this to say about = timeouts: "It may be desirable to have table aging and/or timeouts. The implementation of these is outside the scope of this protocol." This new code does not change the default value of either the arpqueue = (which was always 1 packet) nor does it change the new value of the ARP down = timeout. I have a different patch for 7, which I will propose after I can get = this in to HEAD and MFC'd to 8. Best, George 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). From owner-freebsd-arch@FreeBSD.ORG Wed Nov 3 00:14:36 2010 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DBDF9106566B; Wed, 3 Nov 2010 00:14:36 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 7BBEF8FC15; Wed, 3 Nov 2010 00:14:36 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.3/8.14.1) with ESMTP id oA307Z5E026529; Tue, 2 Nov 2010 18:07:36 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Tue, 02 Nov 2010 18:07:35 -0600 (MDT) Message-Id: <20101102.180735.74725412.imp@bsdimp.com> To: uqs@spoerlein.net From: Warner Losh In-Reply-To: <20101028205815.GF46314@acme.spoerlein.net> References: <20101028205815.GF46314@acme.spoerlein.net> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: attilio@freebsd.org, arch@freebsd.org Subject: Re: [PATCH] Headers for the x86 subtree 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, 03 Nov 2010 00:14:36 -0000 From: Ulrich Sp=F6rlein Subject: Re: [PATCH] Headers for the x86 subtree Date: Thu, 28 Oct 2010 22:58:15 +0200 > On Wed, 27.10.2010 at 16:56:06 +0200, Attilio Rao wrote: > > This patch should convert a (simple and 100% shared between amd64 a= nd > > i386 header) under the x86 sub-tree. Please note that in this patch= I > > "svn cp" the file from sys/amd64/include/mptable.h into > > sys/x86/include/mptable.h: > > http://www.freebsd.org/~attilio/headers-x86.diff > > = > > This is someway a POC, that I really want to get in. The idea is > > simple and someway follows the pc98 case (even if not entirely): th= e > > files under machine/include/* became just mere stubs for x86/includ= e/* > > contents and redirect there. > > This won't particulary help reducing the number of available files,= > > but generally removing verbatim and would also be the way to go for= > > handling MFCs. > > If you find this is the right way I'll commit the fix and start mov= ing > > other files as time permits. > = > What I don't quite get with the new x86 directory is, why we didn't m= ake > it arch/x86 from the start? The usual argument against moving > architecture specific stuff to arch/ is that it will break diffs for > vendors. Now with x86 and the merging we are breaking their stuff > anyway, but we don't actually improve the clutter under /sys and even= > gain a new arch-specific dir, not under arch/ > = > Somehow, this seems like a missed opportunity for an often requested > cleanup. :/ There's a couple of factors that militate against this change: (1) arch/foo means something else in NetBSD and OpenBSD. There, it is overloaded to mean both CPU-specific code, as well as machine specific code. It might be cleaner to move to cpu/foo instead. (2) If we moved to arch/x86, it would be the odd-man out, requiring special cases in a number of places. To make it not the odd-man out would be a lot of work. (3) Given the historical debates about arch/foo, there's a residual recoil issue: nobody wants to touch that electric fence again... Warner From owner-freebsd-arch@FreeBSD.ORG Thu Nov 4 08:06:16 2010 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 582F1106566B; Thu, 4 Nov 2010 08:06:16 +0000 (UTC) (envelope-from rpaulo@freebsd.org) Received: from karen.lavabit.com (karen.lavabit.com [72.249.41.33]) by mx1.freebsd.org (Postfix) with ESMTP id 301B68FC0C; Thu, 4 Nov 2010 08:06:15 +0000 (UTC) Received: from e.earth.lavabit.com (e.earth.lavabit.com [192.168.111.14]) by karen.lavabit.com (Postfix) with ESMTP id 3E1F711B7F2; Thu, 4 Nov 2010 02:42:30 -0500 (CDT) Received: from 172.10.20.2 (84.8.54.77.rev.vodafone.pt [77.54.8.84]) by lavabit.com with ESMTP id TE446NO4XM0F; Thu, 04 Nov 2010 02:42:30 -0500 References: <8C96F018-EA61-4C38-AC9A-148D1DC06193@freebsd.org> In-Reply-To: <8C96F018-EA61-4C38-AC9A-148D1DC06193@freebsd.org> Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii Message-Id: Content-Transfer-Encoding: quoted-printable From: Rui Paulo Date: Thu, 4 Nov 2010 07:42:24 +0000 To: George Neville-Neil X-Mailer: Apple Mail (2.1081) Cc: arch@freebsd.org, net@freebsd.org Subject: Re: RFC: Updated ARP Queue patch... 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: Thu, 04 Nov 2010 08:06:16 -0000 Hi, On 1 Nov 2010, at 19:20, George Neville-Neil wrote: > Howdy, >=20 > This is marked as "Updated" because I first proposed this on arch@ but = am now sending it to > a wider audience as I'm hoping to commit it in the near future. >=20 > Please review the following patch against HEAD: >=20 > http://people.freebsd.org/~gnn/head-arpqueue2.diff >=20 > This patch makes two changes to the ARP code: >=20 > 1) It adds a sysctl configurable queue of packets that are held until = an ARP reply is received or > timed out. >=20 > net.link.ether.inet.maxhold >=20 > Having the queue addresses a problem in modern systems where programs = that use connectionless=20 > protocols for communication will suffer from dropping many packets = when they start up or when > an ARP entry moves. >=20 > 2) Makes the time we wait for an arp reply configurable via another = sysctl. >=20 > net.link.ether.inet.wait >=20 > The old, pre 8.0, ARP code would run the timer once per second. The = new > ARP code sets a timeout of 20 seconds on each entry. Neither value = was specified > in RFC 826. As a matter of fact, RFC 826 had this to say about = timeouts: >=20 > "It may be desirable to have table aging and/or timeouts. The > implementation of these is outside the scope of this protocol." >=20 > This new code does not change the default value of either the arpqueue = (which was > always 1 packet) nor does it change the new value of the ARP down = timeout. >=20 > I have a different patch for 7, which I will propose after I can get = this in to > HEAD and MFC'd to 8. This looks good to me. Regards, -- Rui Paulo From owner-freebsd-arch@FreeBSD.ORG Thu Nov 4 08:37:17 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 1DEE4106566C; Thu, 4 Nov 2010 08:37:17 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe07.swip.net [212.247.154.193]) by mx1.freebsd.org (Postfix) with ESMTP id BCC7D8FC0C; Thu, 4 Nov 2010 08:37:15 +0000 (UTC) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.1 cv=sEolSJAlcSxSMaOm1MQ0bvrIu+BNAN+OqG2UAUgC4Ok= c=1 sm=1 a=FberXtVRn-wA:10 a=Q9fys5e9bTEA:10 a=CL8lFSKtTFcA:10 a=i9M/sDlu2rpZ9XS819oYzg==:17 a=hbYBJcQZDcC0HrEwo7wA:9 a=rdHuChauiKYftlwAyukA:7 a=rp5_LUhrVUki9jaKdWBadY-w694A:4 a=PUjeQqilurYA:10 a=hc5yWR8y822bM0dV:21 a=_9LHc2Q8-2OudMNw:21 a=i9M/sDlu2rpZ9XS819oYzg==:117 Received: from [188.126.198.129] (account mc467741@c2i.net HELO laptop002.hselasky.homeunix.org) by mailfe07.swip.net (CommuniGate Pro SMTP 5.2.19) with ESMTPA id 44321807; Thu, 04 Nov 2010 09:37:13 +0100 From: Hans Petter Selasky To: freebsd-arch@freebsd.org Date: Thu, 4 Nov 2010 09:38:25 +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> <201011020839.45839.hselasky@c2i.net> In-Reply-To: <201011020839.45839.hselasky@c2i.net> 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: <201011040938.25094.hselasky@c2i.net> Cc: Andrew Thompson , freebsd-current@freebsd.org, freebsd-usb@freebsd.org, Weongyo Jeong 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: Thu, 04 Nov 2010 08:37:17 -0000 On Tuesday 02 November 2010 08:39:45 Hans Petter Selasky wrote: > 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). > Any more comments on this matter or someone still doing review? --HPS From owner-freebsd-arch@FreeBSD.ORG Thu Nov 4 13:55:12 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 B482A1065679; Thu, 4 Nov 2010 13:55:12 +0000 (UTC) (envelope-from mdf356@gmail.com) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id BD15E8FC12; Thu, 4 Nov 2010 13:55:10 +0000 (UTC) Received: by iwn39 with SMTP id 39so1442199iwn.13 for ; Thu, 04 Nov 2010 06:55:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=rc6Kf9M4JbqxPQwsiLamXqjZv7hw7qPAbMGIlSL8Prc=; b=lhInRB7GhpdX3uDnyYrOVphBArMV2tL/Uyd60gDHexCc0bXEUPLArOOZgiPRa1Tw/Z OL6h6Vh4BK82OvnMVa2HnpY65OizkAZw9OAxbugup/eNIGmBj43kVwUV4tejVGwL7xjk ttInqLtFa5GrjknG6B8g9TvE0Bb5E9pB8RikA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=is+GRIxG7FlicA8x+7DoC0R9Po5VylH8eu3ln0WTPSFoslwaXPNqJm9he0jJ8/8okT ABuI7NcHTSztRM6vRgUI9YFBWEs7OKjjNKuZCkxzJyFKl1l/SOgiEJLznrln8f+rusZ7 HoR+lUKhuu3qSw++keX/shCIhz7yvui16KNNI= MIME-Version: 1.0 Received: by 10.231.33.203 with SMTP id i11mr490075ibd.8.1288878909370; Thu, 04 Nov 2010 06:55:09 -0700 (PDT) Received: by 10.231.159.198 with HTTP; Thu, 4 Nov 2010 06:55:09 -0700 (PDT) In-Reply-To: <201011012115.15261.hselasky@c2i.net> References: <201011012054.59551.hselasky@c2i.net> <201011012115.15261.hselasky@c2i.net> Date: Thu, 4 Nov 2010 06:55:09 -0700 Message-ID: From: Matthew Fleming To: Hans Petter Selasky Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-arch@freebsd.org, freebsd-current@freebsd.org, Andrew Thompson , freebsd-usb@freebsd.org, Weongyo Jeong 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: Thu, 04 Nov 2010 13:55:12 -0000 On Mon, Nov 1, 2010 at 1:15 PM, Hans Petter Selasky wrot= e: > On Monday 01 November 2010 21:07:29 Matthew Fleming wrote: >> On Mon, Nov 1, 2010 at 12:54 PM, Hans Petter Selasky > wrote: >> > Hi! >> > >> > I've wrapped up an outline patch for what needs to be done to integrat= e >> > 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 >> > >> > :-)] >> >> I'd like to make sure I understand the USB requirements. >> >> (1) does USB need the task priority field? =A0Many taskqueue(9) consumer= s do >> not. > > No, USB does not need a task priority field, but a sequence field associa= ted > with the task and task queue head to figure out which task was queued fir= st > without having to scan all the tasks queued. > >> (2) if there was a working taskqueue_remove(9) that removed the task >> if pending or returned error if the task was currently running, would >> that be sufficient to implement the required USB functionality? >> (assuming that taskqueue_enqueue(9) put all tasks with equal priority >> in order of queueing). > > No, not completely. See comment above. I also need information about whic= h > task was queued first, or else I have to keep this information separately= , > which again, confuse people. The more layers the more confusion? I don't follow why keeping the information about which task was queued first privately rather than having taskqueue(9) maintain it is confusing. So far, USB seems to be the only taskqueue consumer which needs this information, so it makes a lot more sense to me for it to be USB private. To my mind, there's primary operations, and secondary ones. A secondary operation can be built from the primary ones. It reads to me that, if there was a taskqueue_cancel(9) (and there is in Jeff's OFED branch) then you could build the functionality you want (and maybe you don't need cancel, even). While there is sometimes an argument for making secondary operations available in a library, in this case you need extra data which most other taskqueue consumers do not. That would break the KBI. That is another argument in favor of keeping the implementation private to USB. Thanks, matthew From owner-freebsd-arch@FreeBSD.ORG Thu Nov 4 15:08:52 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 D81761065672; Thu, 4 Nov 2010 15:08:52 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe05.swip.net [212.247.154.129]) by mx1.freebsd.org (Postfix) with ESMTP id CAFDE8FC16; Thu, 4 Nov 2010 15:08:51 +0000 (UTC) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.1 cv=5OBHFxb9I47YZ7HELXzI6cL6pwPTRnd5uxbD1DPQ4WY= c=1 sm=1 a=FberXtVRn-wA:10 a=8nJEP1OIZ-IA:10 a=CL8lFSKtTFcA:10 a=i9M/sDlu2rpZ9XS819oYzg==:17 a=8kQB0OdkAAAA:8 a=eBBTKOCzzS4ddj3yubgA:9 a=UVoTL3aoASoHr0WDeJkA:7 a=nXYsBsMJQ5gLzLLRCrZL-R1_Wg0A:4 a=wPNLvfGTeEIA:10 a=9aOQ2cSd83gA:10 a=i9M/sDlu2rpZ9XS819oYzg==:117 Received: from [188.126.198.129] (account mc467741@c2i.net HELO laptop002.hselasky.homeunix.org) by mailfe05.swip.net (CommuniGate Pro SMTP 5.2.19) with ESMTPA id 44175068; Thu, 04 Nov 2010 16:08:49 +0100 From: Hans Petter Selasky To: freebsd-arch@freebsd.org Date: Thu, 4 Nov 2010 16:10:00 +0100 User-Agent: KMail/1.13.5 (FreeBSD/8.1-STABLE; KDE/4.4.5; amd64; ; ) References: <201011012054.59551.hselasky@c2i.net> <201011012115.15261.hselasky@c2i.net> In-Reply-To: X-Face: +~\`s("[*|O,="7?X@L.elg*F"OA\I/3%^p8g?ab%RN'( =?iso-8859-1?q?=3B=5FIjlA=3A=0A=09hGE=2E=2EEw?=, =?iso-8859-1?q?XAQ*o=23=5C/M=7ESC=3DS1-f9=7BEzRfT=27=7CHhll5Q=5Dha5Bt-s=7Co?= =?iso-8859-1?q?TlKMusi=3A1e=5BwJl=7Dkd=7DGR=0A=09Z0adGx-x=5F0zGbZj=27e?=(Y[(UNle~)8CQWXW@:DX+9)_YlB[tIccCPN$7/L' MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201011041610.00736.hselasky@c2i.net> Cc: freebsd-current@freebsd.org, Matthew Fleming , freebsd-usb@freebsd.org, Andrew Thompson , Weongyo Jeong 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: Thu, 04 Nov 2010 15:08:53 -0000 On Thursday 04 November 2010 14:55:09 Matthew Fleming wrote: > On Mon, Nov 1, 2010 at 1:15 PM, Hans Petter Selasky wrote: > > On Monday 01 November 2010 21:07:29 Matthew Fleming wrote: > >> On Mon, Nov 1, 2010 at 12:54 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 > >> > > >> > :-)] > >> > >> I'd like to make sure I understand the USB requirements. > >> > >> (1) does USB need the task priority field? Many taskqueue(9) consumers > >> do not. > > > > No, USB does not need a task priority field, but a sequence field > > associated with the task and task queue head to figure out which task > > was queued first without having to scan all the tasks queued. > > > >> (2) if there was a working taskqueue_remove(9) that removed the task > >> if pending or returned error if the task was currently running, would > >> that be sufficient to implement the required USB functionality? > >> (assuming that taskqueue_enqueue(9) put all tasks with equal priority > >> in order of queueing). > > > > No, not completely. See comment above. I also need information about > > which task was queued first, or else I have to keep this information > > separately, which again, confuse people. The more layers the more > > confusion? Hi, > > I don't follow why keeping the information about which task was queued > first privately rather than having taskqueue(9) maintain it is > confusing. So far, USB seems to be the only taskqueue consumer which > needs this information, so it makes a lot more sense to me for it to > be USB private. Probably I can check which task is pending when I queue them and store that in a separate variable. Still I need a way to remove a task from the queue, which becomes very slow due to the fact that STAILQ() is used. > To my mind, there's primary operations, and secondary ones. A > secondary operation can be built from the primary ones. That is right, if there is a way to remove a task from a queue without draining. > It reads to > me that, if there was a taskqueue_cancel(9) (and there is in Jeff's > OFED branch) then you could build the functionality you want (and > maybe you don't need cancel, even). While there is sometimes an > argument for making secondary operations available in a library, in > this case you need extra data which most other taskqueue consumers do > not. That would break the KBI. That is another argument in favor of > keeping the implementation private to USB. The only reason I want to break the KBI is because it is slow to remove a task from the taskqueue using STAILQ's when you don't know the previous task- element in the queue. --HPS From owner-freebsd-arch@FreeBSD.ORG Thu Nov 4 18:00:34 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 785B71065697; Thu, 4 Nov 2010 18:00:34 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 437AA8FC13; Thu, 4 Nov 2010 18:00:34 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id CBBF946B5B; Thu, 4 Nov 2010 14:00:33 -0400 (EDT) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id BD7D78A009; Thu, 4 Nov 2010 14:00:32 -0400 (EDT) From: John Baldwin To: freebsd-arch@freebsd.org Date: Thu, 4 Nov 2010 10:29:51 -0400 User-Agent: KMail/1.13.5 (FreeBSD/7.3-CBSD-20100819; KDE/4.4.5; amd64; ; ) References: <201011012054.59551.hselasky@c2i.net> <201011012115.15261.hselasky@c2i.net> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201011041029.51864.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Thu, 04 Nov 2010 14:00:32 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.96.3 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-0.3 required=4.2 tests=BAYES_00,DATE_IN_PAST_03_06 autolearn=no version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on bigwig.baldwin.cx Cc: Matthew Fleming , Andrew Thompson , Weongyo Jeong , freebsd-current@freebsd.org, freebsd-usb@freebsd.org, Hans Petter Selasky 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: Thu, 04 Nov 2010 18:00:34 -0000 On Thursday, November 04, 2010 9:55:09 am Matthew Fleming wrote: > On Mon, Nov 1, 2010 at 1:15 PM, Hans Petter Selasky wrote: > > On Monday 01 November 2010 21:07:29 Matthew Fleming wrote: > >> On Mon, Nov 1, 2010 at 12:54 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 > >> > > >> > :-)] > >> > >> I'd like to make sure I understand the USB requirements. > >> > >> (1) does USB need the task priority field? Many taskqueue(9) consumers do > >> not. > > > > No, USB does not need a task priority field, but a sequence field associated > > with the task and task queue head to figure out which task was queued first > > without having to scan all the tasks queued. > > > >> (2) if there was a working taskqueue_remove(9) that removed the task > >> if pending or returned error if the task was currently running, would > >> that be sufficient to implement the required USB functionality? > >> (assuming that taskqueue_enqueue(9) put all tasks with equal priority > >> in order of queueing). > > > > No, not completely. See comment above. I also need information about which > > task was queued first, or else I have to keep this information separately, > > which again, confuse people. The more layers the more confusion? > > I don't follow why keeping the information about which task was queued > first privately rather than having taskqueue(9) maintain it is > confusing. So far, USB seems to be the only taskqueue consumer which > needs this information, so it makes a lot more sense to me for it to > be USB private. > > To my mind, there's primary operations, and secondary ones. A > secondary operation can be built from the primary ones. It reads to > me that, if there was a taskqueue_cancel(9) (and there is in Jeff's > OFED branch) then you could build the functionality you want (and > maybe you don't need cancel, even). While there is sometimes an > argument for making secondary operations available in a library, in > this case you need extra data which most other taskqueue consumers do > not. That would break the KBI. That is another argument in favor of > keeping the implementation private to USB. My sense is that I certainly agree. The fact that you can't think of a good name for the operation certainly indicates that it is not generic. Unfortunately, I don't really understand the problem that is being solved. I do agree that due to the 'pending' feature and automatic-coalescing of task enqueue operations, taskqueues do not lend themselves to a barrier operation. -- John Baldwin From owner-freebsd-arch@FreeBSD.ORG Thu Nov 4 18:40: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 8690E1065675; Thu, 4 Nov 2010 18:40:02 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe05.swip.net [212.247.154.129]) by mx1.freebsd.org (Postfix) with ESMTP id 476438FC18; Thu, 4 Nov 2010 18:40:00 +0000 (UTC) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.1 cv=5OBHFxb9I47YZ7HELXzI6cL6pwPTRnd5uxbD1DPQ4WY= c=1 sm=1 a=FberXtVRn-wA:10 a=8nJEP1OIZ-IA:10 a=CL8lFSKtTFcA:10 a=i9M/sDlu2rpZ9XS819oYzg==:17 a=iww12FFwlFl3aLusVMYA:9 a=G2MUKtwv3xM2W6zJlr3T7OYMlNgA:4 a=wPNLvfGTeEIA:10 a=i9M/sDlu2rpZ9XS819oYzg==:117 Received: from [188.126.198.129] (account mc467741@c2i.net HELO laptop002.hselasky.homeunix.org) by mailfe05.swip.net (CommuniGate Pro SMTP 5.2.19) with ESMTPA id 44269867; Thu, 04 Nov 2010 19:40:00 +0100 From: Hans Petter Selasky To: John Baldwin Date: Thu, 4 Nov 2010 19:41:09 +0100 User-Agent: KMail/1.13.5 (FreeBSD/8.1-STABLE; KDE/4.4.5; amd64; ; ) References: <201011012054.59551.hselasky@c2i.net> <201011041029.51864.jhb@freebsd.org> In-Reply-To: <201011041029.51864.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-1" Content-Transfer-Encoding: 7bit Message-Id: <201011041941.09662.hselasky@c2i.net> Cc: Matthew Fleming , Andrew Thompson , Weongyo Jeong , freebsd-current@freebsd.org, freebsd-usb@freebsd.org, 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: Thu, 04 Nov 2010 18:40:02 -0000 On Thursday 04 November 2010 15:29:51 John Baldwin wrote: > (and there is in Jeff's OFED branch) Is there a link to this branch? I would certainly have a look at his work and re-base my patch. --HPS From owner-freebsd-arch@FreeBSD.ORG Thu Nov 4 19:02:00 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 11E3A106564A; Thu, 4 Nov 2010 19:02:00 +0000 (UTC) (envelope-from mdf356@gmail.com) Received: from mail-yw0-f54.google.com (mail-yw0-f54.google.com [209.85.213.54]) by mx1.freebsd.org (Postfix) with ESMTP id 6C6778FC08; Thu, 4 Nov 2010 19:01:59 +0000 (UTC) Received: by ywh2 with SMTP id 2so1768476ywh.13 for ; Thu, 04 Nov 2010 12:01:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=I1HBTmal4wdj7RoHcpK5ZAj42DF8gXyVmwLeiE2VbIg=; b=GQKlLEbUB+NgCPMZ8Sh3T1JaNUKdIdsBeAdRgeiixFoTHCPaOAilAoxFXIJIJwBNGS xISQXfnZgWh8Wpe5NYtrnNcyxL5+wduOohtvnZljsgjn/4z/OR8ZHXIXWQ3QUSwWFhDL 9EzEK6wfPqwJGuGpFwSHNy37uKGqa9eL0+xW0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=oElfcZT08ZfGcR0F3YxBLm5qIlWQ0b8xnZo4wi1DTHgglfJUyDZ4LUDE5pa+UlHpGG NQKkhF2l7TvTmzvckiYVyXnZ5Otb2ToXBJ647/yN1QL1AUXkay9uSoUDVl1Wd+suGeXs 30sT0OF9PcBxmM33I16NnvDVGUmzO+wN+VP9E= MIME-Version: 1.0 Received: by 10.42.97.67 with SMTP id m3mr657740icn.343.1288897317938; Thu, 04 Nov 2010 12:01:57 -0700 (PDT) Received: by 10.231.159.198 with HTTP; Thu, 4 Nov 2010 12:01:57 -0700 (PDT) In-Reply-To: <201011041941.09662.hselasky@c2i.net> References: <201011012054.59551.hselasky@c2i.net> <201011041029.51864.jhb@freebsd.org> <201011041941.09662.hselasky@c2i.net> Date: Thu, 4 Nov 2010 12:01:57 -0700 Message-ID: From: Matthew Fleming To: Hans Petter Selasky Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Andrew Thompson , Weongyo Jeong , freebsd-current@freebsd.org, freebsd-usb@freebsd.org, 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: Thu, 04 Nov 2010 19:02:00 -0000 On Thu, Nov 4, 2010 at 11:41 AM, Hans Petter Selasky wro= te: > On Thursday 04 November 2010 15:29:51 John Baldwin wrote: >> =A0(and there is in Jeff's OFED branch) > > Is there a link to this branch? I would certainly have a look at his work= and > re-base my patch. It's on svn.freebsd.org: http://svn.freebsd.org/viewvc/base/projects/ofed/head/sys/kern/subr_taskque= ue.c?view=3Dlog http://svn.freebsd.org/viewvc/base?view=3Drevision&revision=3D209422 For the purpose of speed, I'm not opposed to breaking the KBI by using a doubly-linked TAILQ, but I don't think the difference will matter all that often (perhaps I'm wrong and some taskqueues have dozens of pending tasks?) Thanks, matthew From owner-freebsd-arch@FreeBSD.ORG Thu Nov 4 19:07:41 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 5CDCA106566B; Thu, 4 Nov 2010 19:07:41 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe01.swip.net [212.247.154.1]) by mx1.freebsd.org (Postfix) with ESMTP id 1AE618FC08; Thu, 4 Nov 2010 19:07:39 +0000 (UTC) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.1 cv=omSrwDgyMf70S47Fr5SNr0rQzcmIOo0IafWlB/wSLLo= c=1 sm=1 a=FberXtVRn-wA:10 a=8nJEP1OIZ-IA:10 a=CL8lFSKtTFcA:10 a=i9M/sDlu2rpZ9XS819oYzg==:17 a=qRdCxWWPLfbE3fxGEroA:9 a=UEHWcmcm-zK5qilDy1FloXSCRVoA:4 a=wPNLvfGTeEIA:10 a=i9M/sDlu2rpZ9XS819oYzg==:117 Received: from [188.126.198.129] (account mc467741@c2i.net HELO laptop002.hselasky.homeunix.org) by mailfe01.swip.net (CommuniGate Pro SMTP 5.2.19) with ESMTPA id 45408163; Thu, 04 Nov 2010 20:07:38 +0100 From: Hans Petter Selasky To: Matthew Fleming Date: Thu, 4 Nov 2010 20:08:47 +0100 User-Agent: KMail/1.13.5 (FreeBSD/8.1-STABLE; KDE/4.4.5; amd64; ; ) References: <201011012054.59551.hselasky@c2i.net> <201011041941.09662.hselasky@c2i.net> In-Reply-To: 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-1" Content-Transfer-Encoding: 7bit Message-Id: <201011042008.47703.hselasky@c2i.net> Cc: Andrew Thompson , Weongyo Jeong , freebsd-current@freebsd.org, freebsd-usb@freebsd.org, 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: Thu, 04 Nov 2010 19:07:41 -0000 On Thursday 04 November 2010 20:01:57 Matthew Fleming wrote: > For the purpose of speed, I'm not opposed to breaking the KBI by using > a doubly-linked TAILQ, but I don't think the difference will matter > all that often (perhaps I'm wrong and some taskqueues have dozens of > pending tasks?) Hi, In my case we are talking about 10-15 tasks at maximum. But still (10*9) / 2 = 45 iterations is much more than 2 steps to do the unlink. Anyway. I will have a look at your work and suggest a new patch for my needs. --HPS From owner-freebsd-arch@FreeBSD.ORG Thu Nov 4 19:10: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 99ABF106566C; Thu, 4 Nov 2010 19:10:37 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe01.swip.net [212.247.154.1]) by mx1.freebsd.org (Postfix) with ESMTP id 618C08FC12; Thu, 4 Nov 2010 19:10:35 +0000 (UTC) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.1 cv=omSrwDgyMf70S47Fr5SNr0rQzcmIOo0IafWlB/wSLLo= c=1 sm=1 a=FberXtVRn-wA:10 a=8nJEP1OIZ-IA:10 a=CL8lFSKtTFcA:10 a=i9M/sDlu2rpZ9XS819oYzg==:17 a=8kQB0OdkAAAA:8 a=6I5d2MoRAAAA:8 a=qVhn0TDvtfzDoSz3N8YA:9 a=8QUpVPaYN4w5MPYWOUqInMW9KUQA:4 a=wPNLvfGTeEIA:10 a=9aOQ2cSd83gA:10 a=i9M/sDlu2rpZ9XS819oYzg==:117 Received: from [188.126.198.129] (account mc467741@c2i.net HELO laptop002.hselasky.homeunix.org) by mailfe01.swip.net (CommuniGate Pro SMTP 5.2.19) with ESMTPA id 45409098; Thu, 04 Nov 2010 20:10:35 +0100 From: Hans Petter Selasky To: Matthew Fleming Date: Thu, 4 Nov 2010 20:11:44 +0100 User-Agent: KMail/1.13.5 (FreeBSD/8.1-STABLE; KDE/4.4.5; amd64; ; ) References: <201011012054.59551.hselasky@c2i.net> <201011041941.09662.hselasky@c2i.net> In-Reply-To: X-Face: +~\`s("[*|O,="7?X@L.elg*F"OA\I/3%^p8g?ab%RN'( =?iso-8859-1?q?=3B=5FIjlA=3A=0A=09hGE=2E=2EEw?=, =?iso-8859-1?q?XAQ*o=23=5C/M=7ESC=3DS1-f9=7BEzRfT=27=7CHhll5Q=5Dha5Bt-s=7Co?= =?iso-8859-1?q?TlKMusi=3A1e=5BwJl=7Dkd=7DGR=0A=09Z0adGx-x=5F0zGbZj=27e?=(Y[(UNle~)8CQWXW@:DX+9)_YlB[tIccCPN$7/L' MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201011042011.44705.hselasky@c2i.net> Cc: Andrew Thompson , Weongyo Jeong , freebsd-current@freebsd.org, freebsd-usb@freebsd.org, 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: Thu, 04 Nov 2010 19:10:37 -0000 On Thursday 04 November 2010 20:01:57 Matthew Fleming wrote: > On Thu, Nov 4, 2010 at 11:41 AM, Hans Petter Selasky wrote: > > On Thursday 04 November 2010 15:29:51 John Baldwin wrote: > >> (and there is in Jeff's OFED branch) > > > > Is there a link to this branch? I would certainly have a look at his work > > and re-base my patch. > > It's on svn.freebsd.org: > > http://svn.freebsd.org/viewvc/base/projects/ofed/head/sys/kern/subr_taskque > ue.c?view=log > http://svn.freebsd.org/viewvc/base?view=revision&revision=209422 > > For the purpose of speed, I'm not opposed to breaking the KBI by using > a doubly-linked TAILQ, but I don't think the difference will matter > all that often (perhaps I'm wrong and some taskqueues have dozens of > pending tasks?) > > Thanks, > matthew At first look I see that I need a non-blocking version of: taskqueue_cancel( At the point in the code where these functions are called I cannot block. Is this impossible to implement? --HPS From owner-freebsd-arch@FreeBSD.ORG Thu Nov 4 20:11:40 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 2F3E31065672; Thu, 4 Nov 2010 20:11:40 +0000 (UTC) (envelope-from mdf356@gmail.com) Received: from mail-yx0-f182.google.com (mail-yx0-f182.google.com [209.85.213.182]) by mx1.freebsd.org (Postfix) with ESMTP id A01588FC12; Thu, 4 Nov 2010 20:11:39 +0000 (UTC) Received: by yxl31 with SMTP id 31so1808006yxl.13 for ; Thu, 04 Nov 2010 13:11:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=aMZNkIF9iVlGQqt1uYJpveDEPXRqgwgMV3juNw8lHVc=; b=bof83p7zSh8loU1jljLWlrzmnWbnZmGOVQTEWULbxFIBZ/7FTxByFe8Xp3bUpTggGj Dp+B/iyA5JsczjE4qBLn/CWoPzryt+RYwl49SoDVZoZJR7nQrmcdvxp9ahubeuWiD0Ad hHj2TI7ACzkVnAjaa/ZL8G6u5EVq9stEzeNWc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=v36Ozpxmqlcl2vlCGYLLjRFENZR9EXPndpzn6FqP4TfXZ6kOEqPP5fnyT4ghyQ+ATQ mMa/e1drhQIi4LKuTwmigwjn6ZciO1RzZF38R6vhSZFJHFpM4SmUIqWva1qOwKMCMX7+ 59Yjgqdo49ABDSECfC//RUCJfANWoegPUlF6I= MIME-Version: 1.0 Received: by 10.42.97.67 with SMTP id m3mr731997icn.343.1288901498679; Thu, 04 Nov 2010 13:11:38 -0700 (PDT) Received: by 10.231.159.198 with HTTP; Thu, 4 Nov 2010 13:11:38 -0700 (PDT) In-Reply-To: <201011042011.44705.hselasky@c2i.net> References: <201011012054.59551.hselasky@c2i.net> <201011041941.09662.hselasky@c2i.net> <201011042011.44705.hselasky@c2i.net> Date: Thu, 4 Nov 2010 13:11:38 -0700 Message-ID: From: Matthew Fleming To: Hans Petter Selasky Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-arch@freebsd.org, freebsd-current@freebsd.org, freebsd-usb@freebsd.org, Andrew Thompson , Weongyo Jeong 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: Thu, 04 Nov 2010 20:11:40 -0000 On Thu, Nov 4, 2010 at 12:11 PM, Hans Petter Selasky wro= te: > On Thursday 04 November 2010 20:01:57 Matthew Fleming wrote: >> On Thu, Nov 4, 2010 at 11:41 AM, Hans Petter Selasky > wrote: >> > On Thursday 04 November 2010 15:29:51 John Baldwin wrote: >> >> =A0(and there is in Jeff's OFED branch) >> > >> > Is there a link to this branch? I would certainly have a look at his w= ork >> > and re-base my patch. >> >> It's on svn.freebsd.org: >> >> http://svn.freebsd.org/viewvc/base/projects/ofed/head/sys/kern/subr_task= que >> ue.c?view=3Dlog >> http://svn.freebsd.org/viewvc/base?view=3Drevision&revision=3D209422 >> >> For the purpose of speed, I'm not opposed to breaking the KBI by using >> a doubly-linked TAILQ, but I don't think the difference will matter >> all that often (perhaps I'm wrong and some taskqueues have dozens of >> pending tasks?) >> >> Thanks, >> matthew > > At first look I see that I need a non-blocking version of: > > taskqueue_cancel( > > At the point in the code where these functions are called I cannot block.= Is > this impossible to implement? It depends on whether the queue uses a MTX_SPIN or MTX_DEF. It is not possible to determine whether a task is running without taking the taskqueue lock. And it is certainly impossible to dequeue a task without the lock that was used to enqueue it. However, a variant that dequeued if the task was still pending, and returned failure otherwise (rather than sleeping) is definitely possible. Thanks, matthew From owner-freebsd-arch@FreeBSD.ORG Thu Nov 4 20:14:09 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 706F8106566B; Thu, 4 Nov 2010 20:14:09 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe01.swip.net [212.247.154.1]) by mx1.freebsd.org (Postfix) with ESMTP id 5ADBA8FC08; Thu, 4 Nov 2010 20:14:07 +0000 (UTC) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.1 cv=omSrwDgyMf70S47Fr5SNr0rQzcmIOo0IafWlB/wSLLo= c=1 sm=1 a=FberXtVRn-wA:10 a=8nJEP1OIZ-IA:10 a=CL8lFSKtTFcA:10 a=i9M/sDlu2rpZ9XS819oYzg==:17 a=8kQB0OdkAAAA:8 a=6I5d2MoRAAAA:8 a=0QwtpmV1rXepT5CfuEUA:9 a=eS946g9CBUxHvd1zr24A:7 a=CZwjQWI-HvlaZHoSd6vtHMF60NkA:4 a=wPNLvfGTeEIA:10 a=9aOQ2cSd83gA:10 a=i9M/sDlu2rpZ9XS819oYzg==:117 Received: from [188.126.198.129] (account mc467741@c2i.net HELO laptop002.hselasky.homeunix.org) by mailfe01.swip.net (CommuniGate Pro SMTP 5.2.19) with ESMTPA id 45433961; Thu, 04 Nov 2010 21:14:06 +0100 From: Hans Petter Selasky To: Matthew Fleming Date: Thu, 4 Nov 2010 21:15:16 +0100 User-Agent: KMail/1.13.5 (FreeBSD/8.1-STABLE; KDE/4.4.5; amd64; ; ) References: <201011012054.59551.hselasky@c2i.net> <201011042011.44705.hselasky@c2i.net> In-Reply-To: X-Face: +~\`s("[*|O,="7?X@L.elg*F"OA\I/3%^p8g?ab%RN'( =?iso-8859-1?q?=3B=5FIjlA=3A=0A=09hGE=2E=2EEw?=, =?iso-8859-1?q?XAQ*o=23=5C/M=7ESC=3DS1-f9=7BEzRfT=27=7CHhll5Q=5Dha5Bt-s=7Co?= =?iso-8859-1?q?TlKMusi=3A1e=5BwJl=7Dkd=7DGR=0A=09Z0adGx-x=5F0zGbZj=27e?=(Y[(UNle~)8CQWXW@:DX+9)_YlB[tIccCPN$7/L' MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201011042115.16187.hselasky@c2i.net> Cc: freebsd-arch@freebsd.org, freebsd-current@freebsd.org, freebsd-usb@freebsd.org, Andrew Thompson , Weongyo Jeong 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: Thu, 04 Nov 2010 20:14:09 -0000 On Thursday 04 November 2010 21:11:38 Matthew Fleming wrote: > On Thu, Nov 4, 2010 at 12:11 PM, Hans Petter Selasky wrote: > > On Thursday 04 November 2010 20:01:57 Matthew Fleming wrote: > >> On Thu, Nov 4, 2010 at 11:41 AM, Hans Petter Selasky > > > > wrote: > >> > On Thursday 04 November 2010 15:29:51 John Baldwin wrote: > >> >> (and there is in Jeff's OFED branch) > >> > > >> > Is there a link to this branch? I would certainly have a look at his > >> > work and re-base my patch. > >> > >> It's on svn.freebsd.org: > >> > >> http://svn.freebsd.org/viewvc/base/projects/ofed/head/sys/kern/subr_task > >> que ue.c?view=log > >> http://svn.freebsd.org/viewvc/base?view=revision&revision=209422 > >> > >> For the purpose of speed, I'm not opposed to breaking the KBI by using > >> a doubly-linked TAILQ, but I don't think the difference will matter > >> all that often (perhaps I'm wrong and some taskqueues have dozens of > >> pending tasks?) > >> > >> Thanks, > >> matthew > > > > At first look I see that I need a non-blocking version of: > > > > taskqueue_cancel( > > > > At the point in the code where these functions are called I cannot block. > > Is this impossible to implement? > > It depends on whether the queue uses a MTX_SPIN or MTX_DEF. It is not > possible to determine whether a task is running without taking the > taskqueue lock. And it is certainly impossible to dequeue a task > without the lock that was used to enqueue it. > > However, a variant that dequeued if the task was still pending, and > returned failure otherwise (rather than sleeping) is definitely > possible. I think that if a task is currently executing, then there should be a drain method for that. I.E. two methods: One to stop and one to cancel/drain. Can you implement this? --HPS From owner-freebsd-arch@FreeBSD.ORG Thu Nov 4 21:23:04 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 4AF90106564A; Thu, 4 Nov 2010 21:23:04 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 14DB98FC13; Thu, 4 Nov 2010 21:23:04 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id AC24446B0D; Thu, 4 Nov 2010 17:23:03 -0400 (EDT) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 9BAD38A009; Thu, 4 Nov 2010 17:23:02 -0400 (EDT) From: John Baldwin To: freebsd-arch@freebsd.org Date: Thu, 4 Nov 2010 17:22:46 -0400 User-Agent: KMail/1.13.5 (FreeBSD/7.3-CBSD-20100819; KDE/4.4.5; amd64; ; ) References: <201011012054.59551.hselasky@c2i.net> <201011042115.16187.hselasky@c2i.net> In-Reply-To: <201011042115.16187.hselasky@c2i.net> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201011041722.46673.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Thu, 04 Nov 2010 17:23:02 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.96.3 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-1.9 required=4.2 tests=BAYES_00 autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on bigwig.baldwin.cx Cc: Matthew Fleming , freebsd-usb@freebsd.org, Weongyo Jeong , freebsd-current@freebsd.org, Andrew Thompson , Hans Petter Selasky 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: Thu, 04 Nov 2010 21:23:04 -0000 On Thursday, November 04, 2010 4:15:16 pm Hans Petter Selasky wrote: > On Thursday 04 November 2010 21:11:38 Matthew Fleming wrote: > > On Thu, Nov 4, 2010 at 12:11 PM, Hans Petter Selasky > wrote: > > > On Thursday 04 November 2010 20:01:57 Matthew Fleming wrote: > > >> On Thu, Nov 4, 2010 at 11:41 AM, Hans Petter Selasky > > > > > > wrote: > > >> > On Thursday 04 November 2010 15:29:51 John Baldwin wrote: > > >> >> (and there is in Jeff's OFED branch) > > >> > > > >> > Is there a link to this branch? I would certainly have a look at his > > >> > work and re-base my patch. > > >> > > >> It's on svn.freebsd.org: > > >> > > >> http://svn.freebsd.org/viewvc/base/projects/ofed/head/sys/kern/subr_task > > >> que ue.c?view=log > > >> http://svn.freebsd.org/viewvc/base?view=revision&revision=209422 > > >> > > >> For the purpose of speed, I'm not opposed to breaking the KBI by using > > >> a doubly-linked TAILQ, but I don't think the difference will matter > > >> all that often (perhaps I'm wrong and some taskqueues have dozens of > > >> pending tasks?) > > >> > > >> Thanks, > > >> matthew > > > > > > At first look I see that I need a non-blocking version of: > > > > > > taskqueue_cancel( > > > > > > At the point in the code where these functions are called I cannot block. > > > Is this impossible to implement? > > > > It depends on whether the queue uses a MTX_SPIN or MTX_DEF. It is not > > possible to determine whether a task is running without taking the > > taskqueue lock. And it is certainly impossible to dequeue a task > > without the lock that was used to enqueue it. > > > > However, a variant that dequeued if the task was still pending, and > > returned failure otherwise (rather than sleeping) is definitely > > possible. > > I think that if a task is currently executing, then there should be a drain > method for that. I.E. two methods: One to stop and one to cancel/drain. Can > you implement this? I agree, this would also be consistent with the callout_*() API if you had both "stop()" and "drain()" methods. -- John Baldwin From owner-freebsd-arch@FreeBSD.ORG Thu Nov 4 21:49:24 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 176771065701; Thu, 4 Nov 2010 21:49:24 +0000 (UTC) (envelope-from mdf356@gmail.com) Received: from mail-gw0-f54.google.com (mail-gw0-f54.google.com [74.125.83.54]) by mx1.freebsd.org (Postfix) with ESMTP id 730798FC14; Thu, 4 Nov 2010 21:49:23 +0000 (UTC) Received: by gwj16 with SMTP id 16so1890883gwj.13 for ; Thu, 04 Nov 2010 14:49:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=y5OWkyV0yWOgrJoXXzsMGOw+u+lerBuuB68hIWvCy20=; b=RImZJ053F2jMX3McwHgNha06a1oquosW3mUcVyDYtk3SSbExv0r6H7sWE9HTrmY8hM 66kLZO3FaPGPL1CwwLiCYgqjSGV5bIKLzNpjVCe3JPIgdd4nvaedznesRut/FQs/M06z igr8n4IMQYYZKc+4VwjGP0QPY8ryZBE5y3KCU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=qWa94M36Byq7C0OS+BuSi8WSfDGJHFlkPcQ5jZi23oDSqRXS0nDgDT4yTjJ3EMmvpX hk/6EJN4C0A5ZsePlAGE5z7DWTiZIe2gXq4WNHmTFYJgqVRvwip6K4TgLXnkjH6ZpB/E sv8lof1UM+BhXYDrgAfDgLm9qeSFaADQTCCdE= MIME-Version: 1.0 Received: by 10.42.193.17 with SMTP id ds17mr926521icb.276.1288907362527; Thu, 04 Nov 2010 14:49:22 -0700 (PDT) Received: by 10.231.159.198 with HTTP; Thu, 4 Nov 2010 14:49:22 -0700 (PDT) In-Reply-To: <201011041722.46673.jhb@freebsd.org> References: <201011012054.59551.hselasky@c2i.net> <201011042115.16187.hselasky@c2i.net> <201011041722.46673.jhb@freebsd.org> Date: Thu, 4 Nov 2010 14:49:22 -0700 Message-ID: From: Matthew Fleming To: John Baldwin Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-usb@freebsd.org, Hans Petter Selasky , freebsd-current@freebsd.org, Andrew Thompson , freebsd-arch@freebsd.org, Weongyo Jeong 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: Thu, 04 Nov 2010 21:49:24 -0000 On Thu, Nov 4, 2010 at 2:22 PM, John Baldwin wrote: > On Thursday, November 04, 2010 4:15:16 pm Hans Petter Selasky wrote: >> I think that if a task is currently executing, then there should be a drain >> method for that. I.E. two methods: One to stop and one to cancel/drain. Can >> you implement this? > > I agree, this would also be consistent with the callout_*() API if you had > both "stop()" and "drain()" methods. Here's my proposed code. Note that this builds but is not yet tested. Implement a taskqueue_cancel(9), to cancel a task from a queue. Requested by: hps Original code: jeff MFC after: 1 week http://people.freebsd.org/~mdf/bsd-taskqueue-cancel.diff Thanks, matthew From owner-freebsd-arch@FreeBSD.ORG Fri Nov 5 13:02:49 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 CB301106566C; Fri, 5 Nov 2010 13:02:49 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 97F968FC15; Fri, 5 Nov 2010 13:02:49 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 44EFF46B03; Fri, 5 Nov 2010 09:02:49 -0400 (EDT) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 13C648A009; Fri, 5 Nov 2010 09:02:48 -0400 (EDT) From: John Baldwin To: Matthew Fleming Date: Fri, 5 Nov 2010 08:58:33 -0400 User-Agent: KMail/1.13.5 (FreeBSD/7.3-CBSD-20100819; KDE/4.4.5; amd64; ; ) References: <201011012054.59551.hselasky@c2i.net> <201011041722.46673.jhb@freebsd.org> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201011050858.33568.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Fri, 05 Nov 2010 09:02:48 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.96.3 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-1.9 required=4.2 tests=BAYES_00 autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on bigwig.baldwin.cx Cc: freebsd-usb@freebsd.org, Hans Petter Selasky , freebsd-current@freebsd.org, Andrew Thompson , freebsd-arch@freebsd.org, Weongyo Jeong 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: Fri, 05 Nov 2010 13:02:50 -0000 On Thursday, November 04, 2010 5:49:22 pm Matthew Fleming wrote: > On Thu, Nov 4, 2010 at 2:22 PM, John Baldwin wrote: > > On Thursday, November 04, 2010 4:15:16 pm Hans Petter Selasky wrote: > >> I think that if a task is currently executing, then there should be a drain > >> method for that. I.E. two methods: One to stop and one to cancel/drain. Can > >> you implement this? > > > > I agree, this would also be consistent with the callout_*() API if you had > > both "stop()" and "drain()" methods. > > Here's my proposed code. Note that this builds but is not yet tested. > > > Implement a taskqueue_cancel(9), to cancel a task from a queue. > > Requested by: hps > Original code: jeff > MFC after: 1 week > > > http://people.freebsd.org/~mdf/bsd-taskqueue-cancel.diff For FreeBSD taskqueue_cancel() should return EBUSY, not -EBUSY. However, I would prefer that it follow the semantics of callout_stop() and return true if it stopped the task and false otherwise. The Linux wrapper for taskqueue_cancel() can convert the return value. I'm not sure I like reusing the memory allocation flags (M_NOWAIT / M_WAITOK) for this blocking flag. In the case of callout(9) we just have two functions that pass an internal boolean to the real routine (callout_stop() and callout_drain() are wrappers for _callout_stop_safe()). It is a bit unfortunate that taskqueue_drain() already exists and has different semantics than callout_drain(). It would have been nice to have the two APIs mirror each other instead. Hmm, I wonder if the blocking behavior cannot safely be provided by just doing: if (!taskqueue_cancel(queue, task, M_NOWAIT) taskqueue_drain(queue, task); If that works ok (I think it does), I would rather have taskqueue_cancel() always be non-blocking. Even though there is a "race" where the task could be rescheduled by another thread in between cancel and drain, the race still exists since if the task could be scheduled between the two, it could also be scheduled just before the call to taskqueue_cancel() (in which case a taskqueue_cancel(queue, task, M_WAITOK) would have blocked to wait for it matching the taskqueue_drain() above). The caller still always has to provide synchronization for preventing a task's execution outright via their own locking. -- John Baldwin From owner-freebsd-arch@FreeBSD.ORG Fri Nov 5 13:50:11 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 CFF81106564A; Fri, 5 Nov 2010 13:50:11 +0000 (UTC) (envelope-from mdf356@gmail.com) Received: from mail-gx0-f182.google.com (mail-gx0-f182.google.com [209.85.161.182]) by mx1.freebsd.org (Postfix) with ESMTP id 3829D8FC16; Fri, 5 Nov 2010 13:50:11 +0000 (UTC) Received: by gxk9 with SMTP id 9so2227881gxk.13 for ; Fri, 05 Nov 2010 06:50:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=yIl7S6Pklw/SCH6aYHWJXvN1x24XuLiY+mRktHJI5+4=; b=B/d0MBW2L/87bSreHOi3atmmuFVloL1pVxaxy5j95LuTPr2Qna9mmEz8a6B6sNc/am wFaAnFP49R4HlckuKsZwR+vyUW1IvX1FG7WUV3GrUjnBKnkAylx8K6UedAf3W3+nn874 Ab/uuQEaD93oxKb+UItcowNAp/te7CFMjvVco= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=MUXkDTTBUlNY4H2xPpUDjbHUCB5wzujANiIZx0H+szwh/fLMoBgl6vMEEJ1fX56+fb AIW1hL81CByB+uxarwwycFNjXyDwVGfLu6qiBag2mSwzIhfwwA8cVYyilsg9KJx516N1 B0Dlol/aUiAEUF13b3pUrQlQ/4Tx8haFpre7w= MIME-Version: 1.0 Received: by 10.42.22.69 with SMTP id n5mr1088729icb.477.1288965010417; Fri, 05 Nov 2010 06:50:10 -0700 (PDT) Received: by 10.231.159.198 with HTTP; Fri, 5 Nov 2010 06:50:10 -0700 (PDT) In-Reply-To: <201011050858.33568.jhb@freebsd.org> References: <201011012054.59551.hselasky@c2i.net> <201011041722.46673.jhb@freebsd.org> <201011050858.33568.jhb@freebsd.org> Date: Fri, 5 Nov 2010 06:50:10 -0700 Message-ID: From: Matthew Fleming To: John Baldwin Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-usb@freebsd.org, Hans Petter Selasky , freebsd-current@freebsd.org, Andrew Thompson , freebsd-arch@freebsd.org, Weongyo Jeong 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: Fri, 05 Nov 2010 13:50:12 -0000 On Fri, Nov 5, 2010 at 5:58 AM, John Baldwin wrote: > On Thursday, November 04, 2010 5:49:22 pm Matthew Fleming wrote: >> On Thu, Nov 4, 2010 at 2:22 PM, John Baldwin wrote: >> > On Thursday, November 04, 2010 4:15:16 pm Hans Petter Selasky wrote: >> >> I think that if a task is currently executing, then there should be a= drain >> >> method for that. I.E. two methods: One to stop and one to cancel/drai= n. Can >> >> you implement this? >> > >> > I agree, this would also be consistent with the callout_*() API if you= had >> > both "stop()" and "drain()" methods. >> >> Here's my proposed code. =A0Note that this builds but is not yet tested. >> >> >> Implement a taskqueue_cancel(9), to cancel a task from a queue. >> >> Requested by: =A0 =A0 =A0 hps >> Original code: =A0 =A0 =A0jeff >> MFC after: =A01 week >> >> >> http://people.freebsd.org/~mdf/bsd-taskqueue-cancel.diff > > For FreeBSD taskqueue_cancel() should return EBUSY, not -EBUSY. =A0Howeve= r, I > would prefer that it follow the semantics of callout_stop() and return tr= ue > if it stopped the task and false otherwise. =A0The Linux wrapper for > taskqueue_cancel() can convert the return value. I used -EBUSY since positive return values reflect the old pending count. ta_pending was zero'd, and I think needs to be to keep the task sane, because all of taskqueue(9) assumes a non-zero ta_pending means the task is queued. I don't know that the caller often needs to know the old value of ta_pending, but it seems simpler to return that as the return value and use -EBUSY than to use an optional pointer to a place to store the old ta_pending just so we can keep the error return positive. Note that phk (IIRC) suggested using -error in the returns for sbuf_drain to indicate the difference between success (> 0 bytes drained) and an error, so FreeBSD now has precedent. I'm not entirely sure that's a good thing, since I am not generally fond of Linux's use of -error, but for some cases it is convenient. But, I'll do this one either way, just let me know if the above hasn't convinced you. > I'm not sure I like reusing the memory allocation flags (M_NOWAIT / M_WAI= TOK) > for this blocking flag. =A0In the case of callout(9) we just have two fun= ctions > that pass an internal boolean to the real routine (callout_stop() and > callout_drain() are wrappers for _callout_stop_safe()). =A0It is a bit > unfortunate that taskqueue_drain() already exists and has different seman= tics > than callout_drain(). =A0It would have been nice to have the two APIs mir= ror each > other instead. > > Hmm, I wonder if the blocking behavior cannot safely be provided by just > doing: > > =A0 =A0 =A0 =A0if (!taskqueue_cancel(queue, task, M_NOWAIT) > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0taskqueue_drain(queue, task); This seems reasonable and correct. I will add a note to the manpage about = this. Thanks, matthew > > If that works ok (I think it does), I would rather have taskqueue_cancel(= ) > always be non-blocking. =A0Even though there is a "race" where the task c= ould > be rescheduled by another thread in between cancel and drain, the race st= ill > exists since if the task could be scheduled between the two, it could als= o > be scheduled just before the call to taskqueue_cancel() (in which case a > taskqueue_cancel(queue, task, M_WAITOK) would have blocked to wait for it > matching the taskqueue_drain() above). =A0The caller still always has to > provide synchronization for preventing a task's execution outright via th= eir > own locking. > > -- > John Baldwin > From owner-freebsd-arch@FreeBSD.ORG Fri Nov 5 14:22:17 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 56EDB106564A; Fri, 5 Nov 2010 14:22:17 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 0FA618FC15; Fri, 5 Nov 2010 14:22:17 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 84A0246B37; Fri, 5 Nov 2010 10:22:16 -0400 (EDT) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 806658A009; Fri, 5 Nov 2010 10:22:15 -0400 (EDT) From: John Baldwin To: Matthew Fleming Date: Fri, 5 Nov 2010 10:18:28 -0400 User-Agent: KMail/1.13.5 (FreeBSD/7.3-CBSD-20100819; KDE/4.4.5; amd64; ; ) References: <201011012054.59551.hselasky@c2i.net> <201011050858.33568.jhb@freebsd.org> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201011051018.28860.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Fri, 05 Nov 2010 10:22:15 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.96.3 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-1.9 required=4.2 tests=BAYES_00 autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on bigwig.baldwin.cx Cc: freebsd-usb@freebsd.org, Hans Petter Selasky , freebsd-current@freebsd.org, Andrew Thompson , freebsd-arch@freebsd.org, Weongyo Jeong 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: Fri, 05 Nov 2010 14:22:17 -0000 On Friday, November 05, 2010 9:50:10 am Matthew Fleming wrote: > On Fri, Nov 5, 2010 at 5:58 AM, John Baldwin wrote: > > On Thursday, November 04, 2010 5:49:22 pm Matthew Fleming wrote: > >> On Thu, Nov 4, 2010 at 2:22 PM, John Baldwin wrote: > >> > On Thursday, November 04, 2010 4:15:16 pm Hans Petter Selasky wrote: > >> >> I think that if a task is currently executing, then there should be a drain > >> >> method for that. I.E. two methods: One to stop and one to cancel/drain. Can > >> >> you implement this? > >> > > >> > I agree, this would also be consistent with the callout_*() API if you had > >> > both "stop()" and "drain()" methods. > >> > >> Here's my proposed code. Note that this builds but is not yet tested. > >> > >> > >> Implement a taskqueue_cancel(9), to cancel a task from a queue. > >> > >> Requested by: hps > >> Original code: jeff > >> MFC after: 1 week > >> > >> > >> http://people.freebsd.org/~mdf/bsd-taskqueue-cancel.diff > > > > For FreeBSD taskqueue_cancel() should return EBUSY, not -EBUSY. However, I > > would prefer that it follow the semantics of callout_stop() and return true > > if it stopped the task and false otherwise. The Linux wrapper for > > taskqueue_cancel() can convert the return value. > > I used -EBUSY since positive return values reflect the old pending > count. ta_pending was zero'd, and I think needs to be to keep the > task sane, because all of taskqueue(9) assumes a non-zero ta_pending > means the task is queued. > > I don't know that the caller often needs to know the old value of > ta_pending, but it seems simpler to return that as the return value > and use -EBUSY than to use an optional pointer to a place to store the > old ta_pending just so we can keep the error return positive. > > Note that phk (IIRC) suggested using -error in the returns for > sbuf_drain to indicate the difference between success (> 0 bytes > drained) and an error, so FreeBSD now has precedent. I'm not entirely > sure that's a good thing, since I am not generally fond of Linux's use > of -error, but for some cases it is convenient. > > But, I'll do this one either way, just let me know if the above hasn't > convinced you. Hmm, I hadn't considered if callers would want to know the pending count of the cancelled task. > > I'm not sure I like reusing the memory allocation flags (M_NOWAIT / M_WAITOK) > > for this blocking flag. In the case of callout(9) we just have two functions > > that pass an internal boolean to the real routine (callout_stop() and > > callout_drain() are wrappers for _callout_stop_safe()). It is a bit > > unfortunate that taskqueue_drain() already exists and has different semantics > > than callout_drain(). It would have been nice to have the two APIs mirror each > > other instead. > > > > Hmm, I wonder if the blocking behavior cannot safely be provided by just > > doing: > > > > if (!taskqueue_cancel(queue, task, M_NOWAIT) > > taskqueue_drain(queue, task); > > This seems reasonable and correct. I will add a note to the manpage about this. In that case, would you be fine with dropping the blocking functionality from taskqueue_cancel() completely and requiring code that wants the blocking semantics to use a cancel followed by a drain? -- John Baldwin From owner-freebsd-arch@FreeBSD.ORG Fri Nov 5 16:28:26 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 1BBD71065672 for ; Fri, 5 Nov 2010 16:28:26 +0000 (UTC) (envelope-from baptiste.daroussin@gmail.com) Received: from mail-yw0-f54.google.com (mail-yw0-f54.google.com [209.85.213.54]) by mx1.freebsd.org (Postfix) with ESMTP id C8F038FC18 for ; Fri, 5 Nov 2010 16:28:25 +0000 (UTC) Received: by ywh2 with SMTP id 2so2398200ywh.13 for ; Fri, 05 Nov 2010 09:28:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:content-type; bh=4fgPVNpSO0H6qEYcHJRO+HnKR68E0ZT1CyzIwEUbe/w=; b=hXwPrAzvsIcPMWY0KsXPaL42GAAbYnZ8uwssuXMiAZq/ctMm1mwxqzKIrJqZCbnhBF 9bDBKaqVcs6EvINkwRQRiBroLl7mDnelwLFcE4oxH0DCwLZcYUBlUI2plnb7bSMjvsdZ slK7mPnA5fD8y+IHo32Mb7CEiToChpF90kPx8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; b=eOukHWJ65ruz8jz+5TFSupPeKjs6w+ewIrG5SuQPT6DZSd1gGlEodde6wBtA5nB+P9 T6BbKoMR6qaLgkZaqj9DltW/KXmx0ctt06Ei6IMF05YRkK/aSGLtc90K8ZrdXMe18kED lae2kQQHBqF/ZzeTa1Jb7Z5iA74J6GEI/RZTg= MIME-Version: 1.0 Received: by 10.42.197.72 with SMTP id ej8mr1504332icb.196.1288972735864; Fri, 05 Nov 2010 08:58:55 -0700 (PDT) Sender: baptiste.daroussin@gmail.com Received: by 10.231.192.76 with HTTP; Fri, 5 Nov 2010 08:58:55 -0700 (PDT) In-Reply-To: References: Date: Fri, 5 Nov 2010 16:58:55 +0100 X-Google-Sender-Auth: rgrPHVKdbFrCgyfj7dvkc8ISkeI Message-ID: From: Baptiste Daroussin To: freebsd-arch@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Fwd: [PATCH] update to the latest libedit version and remove libreadline deps 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: Fri, 05 Nov 2010 16:28:26 -0000 Hi, I have been told that this list is betted suited for that kind of patches. regards, Bapt ---------- Forwarded message ---------- From: Baptiste Daroussin Date: 2010/11/5 Subject: [PATCH] update to the latest libedit version and remove libreadline deps To: freebsd-hackers@freebsd.org Hi all, I've updated libedit to the latest version available in the netbsd cvs. UTF8 support is disabled for now has it seems to be experimental and segfault. I also patch and tested all the sources that used to be linked against libreadline so that it now uses libedit making libreadline unused (I guess, perhaps I have missed some) beware that there are collision between libreadline and libedit (/usr/include/readline/readline.h) is provided by both of them. You can find the patch against current here: http://people.freebsd.org/~bapt/update-libedit.patch regards, Bapt From owner-freebsd-arch@FreeBSD.ORG Fri Nov 5 17:15:03 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 5DFBF1065670; Fri, 5 Nov 2010 17:15:03 +0000 (UTC) (envelope-from mdf356@gmail.com) Received: from mail-gy0-f182.google.com (mail-gy0-f182.google.com [209.85.160.182]) by mx1.freebsd.org (Postfix) with ESMTP id B19B58FC1B; Fri, 5 Nov 2010 17:15:02 +0000 (UTC) Received: by gya6 with SMTP id 6so2387413gya.13 for ; Fri, 05 Nov 2010 10:15:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=VxEAITq6iW6923DUMnI8WPm53m8GXLHaC47ypEY4544=; b=gxfxLyi6WvH5ihTkco42ygIrz2EG4P/ZwoiYeHvS0mc0CB8idVzF/bapNukHxaLz/Z 7oibcCB3VaFyeQRbhnfCkoq8mD6RigqBAVGf2siUc+lIc19I7dyUJkV1EBhKAL/UWMvY 106XGEHuhaRaO1CDJL4Nk6gzlizfl8C+HEASw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=B8WxiybCw03FjnlaDcMTTiGqADLtjDKTUBVe28XLTRcLfTiKa+cLAHEy2Lcvg98Trx ux0+BohG5auOALzhvha0pkXcqVVM3xMdjLSWA6rBMNPtJizjEnvDWMIpnV7dtOBxSijX YRtNFRAiG+i1+XyYKglBxxSVULP9MRLZFm+KI= MIME-Version: 1.0 Received: by 10.42.193.17 with SMTP id ds17mr1600934icb.276.1288977301642; Fri, 05 Nov 2010 10:15:01 -0700 (PDT) Received: by 10.231.159.198 with HTTP; Fri, 5 Nov 2010 10:15:01 -0700 (PDT) In-Reply-To: <201011051018.28860.jhb@freebsd.org> References: <201011012054.59551.hselasky@c2i.net> <201011050858.33568.jhb@freebsd.org> <201011051018.28860.jhb@freebsd.org> Date: Fri, 5 Nov 2010 10:15:01 -0700 Message-ID: From: Matthew Fleming To: John Baldwin Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-usb@freebsd.org, Hans Petter Selasky , freebsd-current@freebsd.org, Andrew Thompson , freebsd-arch@freebsd.org, Weongyo Jeong 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: Fri, 05 Nov 2010 17:15:03 -0000 On Fri, Nov 5, 2010 at 7:18 AM, John Baldwin wrote: > On Friday, November 05, 2010 9:50:10 am Matthew Fleming wrote: >> On Fri, Nov 5, 2010 at 5:58 AM, John Baldwin wrote: >> > On Thursday, November 04, 2010 5:49:22 pm Matthew Fleming wrote: >> >> On Thu, Nov 4, 2010 at 2:22 PM, John Baldwin wrote: >> >> > On Thursday, November 04, 2010 4:15:16 pm Hans Petter Selasky wrote= : >> >> >> I think that if a task is currently executing, then there should b= e a drain >> >> >> method for that. I.E. two methods: One to stop and one to cancel/d= rain. Can >> >> >> you implement this? >> >> > >> >> > I agree, this would also be consistent with the callout_*() API if = you had >> >> > both "stop()" and "drain()" methods. >> >> >> >> Here's my proposed code. =A0Note that this builds but is not yet test= ed. >> >> >> >> >> >> Implement a taskqueue_cancel(9), to cancel a task from a queue. >> >> >> >> Requested by: =A0 =A0 =A0 hps >> >> Original code: =A0 =A0 =A0jeff >> >> MFC after: =A01 week >> >> >> >> >> >> http://people.freebsd.org/~mdf/bsd-taskqueue-cancel.diff >> > >> > For FreeBSD taskqueue_cancel() should return EBUSY, not -EBUSY. =A0How= ever, I >> > would prefer that it follow the semantics of callout_stop() and return= true >> > if it stopped the task and false otherwise. =A0The Linux wrapper for >> > taskqueue_cancel() can convert the return value. >> >> I used -EBUSY since positive return values reflect the old pending >> count. =A0ta_pending was zero'd, and I think needs to be to keep the >> task sane, because all of taskqueue(9) assumes a non-zero ta_pending >> means the task is queued. >> >> I don't know that the caller often needs to know the old value of >> ta_pending, but it seems simpler to return that as the return value >> and use -EBUSY than to use an optional pointer to a place to store the >> old ta_pending just so we can keep the error return positive. >> >> Note that phk (IIRC) suggested using -error in the returns for >> sbuf_drain to indicate the difference between success (> 0 bytes >> drained) and an error, so FreeBSD now has precedent. =A0I'm not entirely >> sure that's a good thing, since I am not generally fond of Linux's use >> of -error, but for some cases it is convenient. >> >> But, I'll do this one either way, just let me know if the above hasn't >> convinced you. > > Hmm, I hadn't considered if callers would want to know the pending count = of > the cancelled task. > >> > I'm not sure I like reusing the memory allocation flags (M_NOWAIT / M_= WAITOK) >> > for this blocking flag. =A0In the case of callout(9) we just have two = functions >> > that pass an internal boolean to the real routine (callout_stop() and >> > callout_drain() are wrappers for _callout_stop_safe()). =A0It is a bit >> > unfortunate that taskqueue_drain() already exists and has different se= mantics >> > than callout_drain(). =A0It would have been nice to have the two APIs = mirror each >> > other instead. >> > >> > Hmm, I wonder if the blocking behavior cannot safely be provided by ju= st >> > doing: >> > >> > =A0 =A0 =A0 =A0if (!taskqueue_cancel(queue, task, M_NOWAIT) >> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0taskqueue_drain(queue, task); >> >> This seems reasonable and correct. =A0I will add a note to the manpage a= bout this. > > In that case, would you be fine with dropping the blocking functionality = from > taskqueue_cancel() completely and requiring code that wants the blocking > semantics to use a cancel followed by a drain? New patch is at http://people.freebsd.org/~mdf/0001-Implement-taskqueue_cancel-9-to-cancel-= a-task-from-a.patch I'll try to set up something to test it today too. Thanks, matthew From owner-freebsd-arch@FreeBSD.ORG Fri Nov 5 17:35:34 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 51B0E1065675; Fri, 5 Nov 2010 17:35:34 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe03.swip.net [212.247.154.65]) by mx1.freebsd.org (Postfix) with ESMTP id 1015A8FC12; Fri, 5 Nov 2010 17:35:32 +0000 (UTC) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.1 cv=iBCGAMPDYtSF9sDXX85uHY3wcnYctfVT8vFpe3qPflY= c=1 sm=1 a=FberXtVRn-wA:10 a=8nJEP1OIZ-IA:10 a=CL8lFSKtTFcA:10 a=i9M/sDlu2rpZ9XS819oYzg==:17 a=6I5d2MoRAAAA:8 a=24NoxT-kmLX8QFLnx5MA:9 a=g0NIqYagmTlxspyxPIgA:7 a=LFkYILy1PJmkOeKz3kPsMjiUSV0A:4 a=wPNLvfGTeEIA:10 a=SV7veod9ZcQA:10 a=i9M/sDlu2rpZ9XS819oYzg==:117 Received: from [188.126.198.129] (account mc467741@c2i.net HELO laptop002.hselasky.homeunix.org) by mailfe03.swip.net (CommuniGate Pro SMTP 5.2.19) with ESMTPA id 45334299; Fri, 05 Nov 2010 18:35:31 +0100 From: Hans Petter Selasky To: freebsd-arch@freebsd.org Date: Fri, 5 Nov 2010 18:36:39 +0100 User-Agent: KMail/1.13.5 (FreeBSD/8.1-STABLE; KDE/4.4.5; amd64; ; ) References: <201011012054.59551.hselasky@c2i.net> <201011051018.28860.jhb@freebsd.org> In-Reply-To: X-Face: +~\`s("[*|O,="7?X@L.elg*F"OA\I/3%^p8g?ab%RN'( =?iso-8859-1?q?=3B=5FIjlA=3A=0A=09hGE=2E=2EEw?=, =?iso-8859-1?q?XAQ*o=23=5C/M=7ESC=3DS1-f9=7BEzRfT=27=7CHhll5Q=5Dha5Bt-s=7Co?= =?iso-8859-1?q?TlKMusi=3A1e=5BwJl=7Dkd=7DGR=0A=09Z0adGx-x=5F0zGbZj=27e?=(Y[(UNle~)8CQWXW@:DX+9)_YlB[tIccCPN$7/L' MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201011051836.39697.hselasky@c2i.net> Cc: Matthew Fleming , freebsd-usb@freebsd.org, Weongyo Jeong , freebsd-current@freebsd.org, Andrew Thompson 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: Fri, 05 Nov 2010 17:35:34 -0000 On Friday 05 November 2010 18:15:01 Matthew Fleming wrote: > On Fri, Nov 5, 2010 at 7:18 AM, John Baldwin wrote: > > On Friday, November 05, 2010 9:50:10 am Matthew Fleming wrote: > >> On Fri, Nov 5, 2010 at 5:58 AM, John Baldwin wrote: > >> > On Thursday, November 04, 2010 5:49:22 pm Matthew Fleming wrote: > >> >> On Thu, Nov 4, 2010 at 2:22 PM, John Baldwin wrote: > >> >> > On Thursday, November 04, 2010 4:15:16 pm Hans Petter Selasky wrote: > >> >> >> I think that if a task is currently executing, then there should > >> >> >> be a drain method for that. I.E. two methods: One to stop and one > >> >> >> to cancel/drain. Can you implement this? > >> >> > > >> >> > I agree, this would also be consistent with the callout_*() API if > >> >> > you had both "stop()" and "drain()" methods. > >> >> > >> >> Here's my proposed code. Note that this builds but is not yet > >> >> tested. > >> >> > >> >> > >> >> Implement a taskqueue_cancel(9), to cancel a task from a queue. > >> >> > >> >> Requested by: hps > >> >> Original code: jeff > >> >> MFC after: 1 week > >> >> > >> >> > >> >> http://people.freebsd.org/~mdf/bsd-taskqueue-cancel.diff > >> > > >> > For FreeBSD taskqueue_cancel() should return EBUSY, not -EBUSY. > >> > However, I would prefer that it follow the semantics of > >> > callout_stop() and return true if it stopped the task and false > >> > otherwise. The Linux wrapper for taskqueue_cancel() can convert the > >> > return value. > >> > >> I used -EBUSY since positive return values reflect the old pending > >> count. ta_pending was zero'd, and I think needs to be to keep the > >> task sane, because all of taskqueue(9) assumes a non-zero ta_pending > >> means the task is queued. > >> > >> I don't know that the caller often needs to know the old value of > >> ta_pending, but it seems simpler to return that as the return value > >> and use -EBUSY than to use an optional pointer to a place to store the > >> old ta_pending just so we can keep the error return positive. > >> > >> Note that phk (IIRC) suggested using -error in the returns for > >> sbuf_drain to indicate the difference between success (> 0 bytes > >> drained) and an error, so FreeBSD now has precedent. I'm not entirely > >> sure that's a good thing, since I am not generally fond of Linux's use > >> of -error, but for some cases it is convenient. > >> > >> But, I'll do this one either way, just let me know if the above hasn't > >> convinced you. > > > > Hmm, I hadn't considered if callers would want to know the pending count > > of the cancelled task. > > > >> > I'm not sure I like reusing the memory allocation flags (M_NOWAIT / > >> > M_WAITOK) for this blocking flag. In the case of callout(9) we just > >> > have two functions that pass an internal boolean to the real routine > >> > (callout_stop() and callout_drain() are wrappers for > >> > _callout_stop_safe()). It is a bit unfortunate that > >> > taskqueue_drain() already exists and has different semantics than > >> > callout_drain(). It would have been nice to have the two APIs mirror > >> > each other instead. > >> > > >> > Hmm, I wonder if the blocking behavior cannot safely be provided by > >> > just doing: > >> > > >> > if (!taskqueue_cancel(queue, task, M_NOWAIT) > >> > taskqueue_drain(queue, task); > >> > >> This seems reasonable and correct. I will add a note to the manpage > >> about this. > > > > In that case, would you be fine with dropping the blocking functionality > > from taskqueue_cancel() completely and requiring code that wants the > > blocking semantics to use a cancel followed by a drain? > > New patch is at > http://people.freebsd.org/~mdf/0001-Implement-taskqueue_cancel-9-to-cancel- > a-task-from-a.patch I think the: + if (!task_is_running(queue, task)) { check needs to be omitted. Else you block the possibility of enqueue and cancel a task while it is actually executing/running ?? --HPS From owner-freebsd-arch@FreeBSD.ORG Fri Nov 5 18:13:10 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 A5515106566B; Fri, 5 Nov 2010 18:13:10 +0000 (UTC) (envelope-from mdf356@gmail.com) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 2F1B68FC15; Fri, 5 Nov 2010 18:13:09 +0000 (UTC) Received: by iwn39 with SMTP id 39so3109127iwn.13 for ; Fri, 05 Nov 2010 11:13:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=5a8cIMwwtaVrYIj5jLPK00hC6AwQ8rbk9A+Q73qydtc=; b=jY/EDRFqecOWlKMh55HRUBWcJU1hzIgxLugVhyKYA7bNHPkX09DDikZd+j0G8sFJm5 BaOB7dbZKkD408Z7J0UQ5/wlrTCwmin/TDhkFi2dZncS56btvbNhU5/KWMU3UcdbzjxT zqJWIf68niCB1rySdzag79K3FKU9LoZ2vcvyI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=Mp4QjUA4/DtYbCeAiL4z2FzdZaxYjqntgMNfpH8bW5uC6GqWv+c4oWX6wiwwdTc5G5 oyPrHf6y/OKA4QEBWqjrMkA8zWVSf8jA7IKIdbkTrEe4/sXdUI5ihXmafF3OWB+9z25X 1m1UGuyLuWuOgC6vDJFJ6BRDsHZv7Egi9CHro= MIME-Version: 1.0 Received: by 10.231.36.11 with SMTP id r11mr2010293ibd.58.1288980788700; Fri, 05 Nov 2010 11:13:08 -0700 (PDT) Received: by 10.231.159.198 with HTTP; Fri, 5 Nov 2010 11:13:08 -0700 (PDT) In-Reply-To: <201011051836.39697.hselasky@c2i.net> References: <201011012054.59551.hselasky@c2i.net> <201011051018.28860.jhb@freebsd.org> <201011051836.39697.hselasky@c2i.net> Date: Fri, 5 Nov 2010 11:13:08 -0700 Message-ID: From: Matthew Fleming To: Hans Petter Selasky Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-usb@freebsd.org, Weongyo Jeong , freebsd-current@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: Fri, 05 Nov 2010 18:13:10 -0000 On Fri, Nov 5, 2010 at 10:36 AM, Hans Petter Selasky wro= te: > On Friday 05 November 2010 18:15:01 Matthew Fleming wrote: >> On Fri, Nov 5, 2010 at 7:18 AM, John Baldwin wrote: >> > On Friday, November 05, 2010 9:50:10 am Matthew Fleming wrote: >> >> On Fri, Nov 5, 2010 at 5:58 AM, John Baldwin wrote: >> >> > On Thursday, November 04, 2010 5:49:22 pm Matthew Fleming wrote: >> >> >> On Thu, Nov 4, 2010 at 2:22 PM, John Baldwin wro= te: >> >> >> > On Thursday, November 04, 2010 4:15:16 pm Hans Petter Selasky wr= ote: >> >> >> >> I think that if a task is currently executing, then there shoul= d >> >> >> >> be a drain method for that. I.E. two methods: One to stop and o= ne >> >> >> >> to cancel/drain. Can you implement this? >> >> >> > >> >> >> > I agree, this would also be consistent with the callout_*() API = if >> >> >> > you had both "stop()" and "drain()" methods. >> >> >> >> >> >> Here's my proposed code. =A0Note that this builds but is not yet >> >> >> tested. >> >> >> >> >> >> >> >> >> Implement a taskqueue_cancel(9), to cancel a task from a queue. >> >> >> >> >> >> Requested by: =A0 =A0 =A0 hps >> >> >> Original code: =A0 =A0 =A0jeff >> >> >> MFC after: =A01 week >> >> >> >> >> >> >> >> >> http://people.freebsd.org/~mdf/bsd-taskqueue-cancel.diff >> >> > >> >> > For FreeBSD taskqueue_cancel() should return EBUSY, not -EBUSY. >> >> > =A0However, I would prefer that it follow the semantics of >> >> > callout_stop() and return true if it stopped the task and false >> >> > otherwise. =A0The Linux wrapper for taskqueue_cancel() can convert = the >> >> > return value. >> >> >> >> I used -EBUSY since positive return values reflect the old pending >> >> count. =A0ta_pending was zero'd, and I think needs to be to keep the >> >> task sane, because all of taskqueue(9) assumes a non-zero ta_pending >> >> means the task is queued. >> >> >> >> I don't know that the caller often needs to know the old value of >> >> ta_pending, but it seems simpler to return that as the return value >> >> and use -EBUSY than to use an optional pointer to a place to store th= e >> >> old ta_pending just so we can keep the error return positive. >> >> >> >> Note that phk (IIRC) suggested using -error in the returns for >> >> sbuf_drain to indicate the difference between success (> 0 bytes >> >> drained) and an error, so FreeBSD now has precedent. =A0I'm not entir= ely >> >> sure that's a good thing, since I am not generally fond of Linux's us= e >> >> of -error, but for some cases it is convenient. >> >> >> >> But, I'll do this one either way, just let me know if the above hasn'= t >> >> convinced you. >> > >> > Hmm, I hadn't considered if callers would want to know the pending cou= nt >> > of the cancelled task. >> > >> >> > I'm not sure I like reusing the memory allocation flags (M_NOWAIT / >> >> > M_WAITOK) for this blocking flag. =A0In the case of callout(9) we j= ust >> >> > have two functions that pass an internal boolean to the real routin= e >> >> > (callout_stop() and callout_drain() are wrappers for >> >> > _callout_stop_safe()). =A0It is a bit unfortunate that >> >> > taskqueue_drain() already exists and has different semantics than >> >> > callout_drain(). =A0It would have been nice to have the two APIs mi= rror >> >> > each other instead. >> >> > >> >> > Hmm, I wonder if the blocking behavior cannot safely be provided by >> >> > just doing: >> >> > >> >> > =A0 =A0 =A0 =A0if (!taskqueue_cancel(queue, task, M_NOWAIT) >> >> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0taskqueue_drain(queue, task); >> >> >> >> This seems reasonable and correct. =A0I will add a note to the manpag= e >> >> about this. >> > >> > In that case, would you be fine with dropping the blocking functionali= ty >> > from taskqueue_cancel() completely and requiring code that wants the >> > blocking semantics to use a cancel followed by a drain? >> >> New patch is at >> http://people.freebsd.org/~mdf/0001-Implement-taskqueue_cancel-9-to-canc= el- >> a-task-from-a.patch > > I think the: > > + =A0 =A0 =A0 if (!task_is_running(queue, task)) { > > check needs to be omitted. Else you block the possibility of enqueue and > cancel a task while it is actually executing/running ?? Huh? If the task is currently running, there's nothing to do except return failure. Task running means it can't be canceled, because... it's running. Thanks, matthew From owner-freebsd-arch@FreeBSD.ORG Fri Nov 5 18:29:32 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 C2C5B106566C; Fri, 5 Nov 2010 18:29:32 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe07.swip.net [212.247.154.193]) by mx1.freebsd.org (Postfix) with ESMTP id D42F58FC1A; Fri, 5 Nov 2010 18:29:31 +0000 (UTC) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.1 cv=sEolSJAlcSxSMaOm1MQ0bvrIu+BNAN+OqG2UAUgC4Ok= c=1 sm=1 a=FberXtVRn-wA:10 a=CL8lFSKtTFcA:10 a=i9M/sDlu2rpZ9XS819oYzg==:17 a=Cw8rU7oRz3VboNDMIlAA:9 a=MUlSQjhuJp0JbwSJUxwIolEPeYMA:4 a=wPNLvfGTeEIA:10 a=FcgzJa1LcXe6IDLysl4A:9 a=XnCYU3IuQVv1LWxiYhsA:7 a=klG2om15o0QNuV1ZETSHBZYqC58A:4 a=i9M/sDlu2rpZ9XS819oYzg==:117 Received: from [188.126.198.129] (account mc467741@c2i.net HELO laptop002.hselasky.homeunix.org) by mailfe07.swip.net (CommuniGate Pro SMTP 5.2.19) with ESMTPA id 45156194; Fri, 05 Nov 2010 19:29:30 +0100 From: Hans Petter Selasky To: freebsd-current@freebsd.org Date: Fri, 5 Nov 2010 19:30:38 +0100 User-Agent: KMail/1.13.5 (FreeBSD/8.1-STABLE; KDE/4.4.5; amd64; ; ) References: <201011012054.59551.hselasky@c2i.net> <201011051836.39697.hselasky@c2i.net> In-Reply-To: <201011051836.39697.hselasky@c2i.net> 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: Multipart/Mixed; boundary="Boundary-00=_O1E1M5DxgzaX2zh" Message-Id: <201011051930.38530.hselasky@c2i.net> Cc: Weongyo Jeong , Matthew Fleming , freebsd-usb@freebsd.org, 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: Fri, 05 Nov 2010 18:29:32 -0000 --Boundary-00=_O1E1M5DxgzaX2zh Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi, In the patch attached to this e-mail I included Matthew Fleming's patch aswell. 1) I renamed taskqueue_cancel() into taskqueue_stop(), hence that resembles the words of the callout and USB API's terminology for doing the same. 2) I turns out I need to have code in subr_taskqueue.c to be able to make the operations atomic. 3) I did not update the manpage in this patch. Will do that before a commit. 4) My patch implements separate state keeping in "struct task_pair", which avoids having to change any KPI's for now, like suggested by John Baldwin I think. 5) In my implementation I hard-coded the priority argument to zero, so that enqueuing is fast. Comments are welcome! --HPS --Boundary-00=_O1E1M5DxgzaX2zh Content-Type: text/x-patch; charset="iso-8859-1"; name="0001-Implement-taskqueue_pair.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="0001-Implement-taskqueue_pair.patch" === kern/subr_taskqueue.c ================================================================== --- kern/subr_taskqueue.c (revision 214796) +++ kern/subr_taskqueue.c (local) @@ -275,6 +275,25 @@ return (0); } +int +taskqueue_stop(struct taskqueue *queue, struct task *task) +{ + int retval = 0; + + TQ_LOCK(queue); + + if (task->ta_pending != 0) { + STAILQ_REMOVE(&queue->tq_queue, task, task, ta_link); + task->ta_pending = 0; + } + if (task_is_running(queue, task)) + retval = EBUSY; + + TQ_UNLOCK(queue); + + return (retval); +} + void taskqueue_drain(struct taskqueue *queue, struct task *task) { @@ -288,6 +307,113 @@ TQ_UNLOCK(queue); } + +int +taskqueue_pair_enqueue(struct taskqueue *queue, struct task_pair *tp) +{ + struct task *task; + int retval; + int j; + + TQ_LOCK(queue); + + j = 0; + if (tp->tp_task[0].ta_pending > 0) + j |= 1; + if (tp->tp_task[1].ta_pending > 0) + j |= 2; + + if (j == 0) { + /* No entries are queued. Just pick a last task. */ + tp->tp_last = 0; + /* Re-queue the last queued task. */ + task = &tp->tp_task[0]; + } else if (j == 1) { + /* There is only one task pending and the other becomes last. */ + tp->tp_last = 1; + /* Re-queue the last queued task. */ + task = &tp->tp_task[1]; + } else if (j == 2) { + /* There is only one task pending and the other becomes last. */ + tp->tp_last = 0; + /* Re-queue the last queued task. */ + task = &tp->tp_task[0]; + } else { + /* Re-queue the last queued task. */ + task = &tp->tp_task[tp->tp_last]; + STAILQ_REMOVE(&queue->tq_queue, task, task, ta_link); + } + + STAILQ_INSERT_TAIL(&queue->tq_queue, task, ta_link); + + retval = tp->tp_last + 1; + /* store the actual order in the pending count */ + task->ta_pending = retval; + + if ((queue->tq_flags & TQ_FLAGS_BLOCKED) == 0) + queue->tq_enqueue(queue->tq_context); + else + queue->tq_flags |= TQ_FLAGS_PENDING; + + TQ_UNLOCK(queue); + + return (retval); +} + +int +taskqueue_pair_stop(struct taskqueue *queue, struct task_pair *tp) +{ + struct task *task; + int retval = 0; + + TQ_LOCK(queue); + + task = &tp->tp_task[0]; + if (task->ta_pending != 0) { + STAILQ_REMOVE(&queue->tq_queue, task, task, ta_link); + task->ta_pending = 0; + } + if (task_is_running(queue, task)) + retval = EBUSY; + + task = &tp->tp_task[1]; + if (task->ta_pending != 0) { + STAILQ_REMOVE(&queue->tq_queue, task, task, ta_link); + task->ta_pending = 0; + } + if (task_is_running(queue, task)) + retval = EBUSY; + + TQ_UNLOCK(queue); + + return (retval); +} + +void +taskqueue_pair_drain(struct taskqueue *queue, struct task_pair *tp) +{ + struct task *task; + + if (!queue->tq_spin) + WITNESS_WARN(WARN_GIANTOK | WARN_SLEEPOK, NULL, __func__); + + TQ_LOCK(queue); +top: + task = &tp->tp_task[0]; + if (task->ta_pending != 0 || task_is_running(queue, task)) { + TQ_SLEEP(queue, task, &queue->tq_mutex, PWAIT, "-", 0); + goto top; + } + + task = &tp->tp_task[1]; + if (task->ta_pending != 0 || task_is_running(queue, task)) { + TQ_SLEEP(queue, task, &queue->tq_mutex, PWAIT, "-", 0); + goto top; + } + + TQ_UNLOCK(queue); +} + static void taskqueue_swi_enqueue(void *context) { === sys/_task.h ================================================================== --- sys/_task.h (revision 214796) +++ sys/_task.h (local) @@ -51,4 +51,9 @@ void *ta_context; /* (c) argument for handler */ }; +struct task_pair { + struct task tp_task[2]; + int tp_last; /* (q) index of last queued task */ +}; + #endif /* !_SYS__TASK_H_ */ === sys/taskqueue.h ================================================================== --- sys/taskqueue.h (revision 214796) +++ sys/taskqueue.h (local) @@ -53,7 +53,11 @@ void *context); int taskqueue_start_threads(struct taskqueue **tqp, int count, int pri, const char *name, ...) __printflike(4, 5); +int taskqueue_pair_enqueue(struct taskqueue *queue, struct task_pair *tp); +int taskqueue_pair_stop(struct taskqueue *queue, struct task_pair *tp); +void taskqueue_pair_drain(struct taskqueue *queue, struct task_pair *tp); int taskqueue_enqueue(struct taskqueue *queue, struct task *task); +int taskqueue_stop(struct taskqueue *queue, struct task *task); void taskqueue_drain(struct taskqueue *queue, struct task *task); void taskqueue_free(struct taskqueue *queue); void taskqueue_run(struct taskqueue *queue); @@ -78,6 +82,15 @@ } while (0) /* + * Initialise a task pair structure. + */ +#define TASK_PAIR_INIT(tp, func, context) do { \ + TASK_INIT(&(tp)->tp_task[0], 0, func, context); \ + TASK_INIT(&(tp)->tp_task[1], 0, func, context); \ + (tp)->tp_last = 0; \ +} while (0) + +/* * Declare a reference to a taskqueue. */ #define TASKQUEUE_DECLARE(name) \ --Boundary-00=_O1E1M5DxgzaX2zh-- From owner-freebsd-arch@FreeBSD.ORG Fri Nov 5 18:34:21 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 D16E0106566B; Fri, 5 Nov 2010 18:34:21 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe06.swip.net [212.247.154.161]) by mx1.freebsd.org (Postfix) with ESMTP id C03C88FC16; Fri, 5 Nov 2010 18:34:20 +0000 (UTC) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.1 cv=5UXFHLfkiY5XrCDma5uYm2T9fyMGz6t0cyN4hLfZsqg= c=1 sm=1 a=FberXtVRn-wA:10 a=8nJEP1OIZ-IA:10 a=CL8lFSKtTFcA:10 a=i9M/sDlu2rpZ9XS819oYzg==:17 a=8kQB0OdkAAAA:8 a=6I5d2MoRAAAA:8 a=NQlS8b5mwfIYmOo8uroA:9 a=E_rvnGVBWsNcG74Lc3UA:7 a=2RIT3NFf099GxrwdX1yFkcDJl_4A:4 a=wPNLvfGTeEIA:10 a=9aOQ2cSd83gA:10 a=SV7veod9ZcQA:10 a=i9M/sDlu2rpZ9XS819oYzg==:117 Received: from [188.126.198.129] (account mc467741@c2i.net HELO laptop002.hselasky.homeunix.org) by mailfe06.swip.net (CommuniGate Pro SMTP 5.2.19) with ESMTPA id 44710663; Fri, 05 Nov 2010 19:34:19 +0100 From: Hans Petter Selasky To: freebsd-arch@freebsd.org Date: Fri, 5 Nov 2010 19:35:27 +0100 User-Agent: KMail/1.13.5 (FreeBSD/8.1-STABLE; KDE/4.4.5; amd64; ; ) References: <201011012054.59551.hselasky@c2i.net> <201011051836.39697.hselasky@c2i.net> In-Reply-To: X-Face: +~\`s("[*|O,="7?X@L.elg*F"OA\I/3%^p8g?ab%RN'( =?iso-8859-1?q?=3B=5FIjlA=3A=0A=09hGE=2E=2EEw?=, =?iso-8859-1?q?XAQ*o=23=5C/M=7ESC=3DS1-f9=7BEzRfT=27=7CHhll5Q=5Dha5Bt-s=7Co?= =?iso-8859-1?q?TlKMusi=3A1e=5BwJl=7Dkd=7DGR=0A=09Z0adGx-x=5F0zGbZj=27e?=(Y[(UNle~)8CQWXW@:DX+9)_YlB[tIccCPN$7/L' MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201011051935.27579.hselasky@c2i.net> Cc: freebsd-current@freebsd.org, Matthew Fleming , Andrew Thompson , freebsd-usb@freebsd.org, Weongyo Jeong 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: Fri, 05 Nov 2010 18:34:22 -0000 On Friday 05 November 2010 19:13:08 Matthew Fleming wrote: > On Fri, Nov 5, 2010 at 10:36 AM, Hans Petter Selasky wrote: > > On Friday 05 November 2010 18:15:01 Matthew Fleming wrote: > >> On Fri, Nov 5, 2010 at 7:18 AM, John Baldwin wrote: > >> > On Friday, November 05, 2010 9:50:10 am Matthew Fleming wrote: > >> >> On Fri, Nov 5, 2010 at 5:58 AM, John Baldwin wrote: > >> >> > On Thursday, November 04, 2010 5:49:22 pm Matthew Fleming wrote: > >> >> >> On Thu, Nov 4, 2010 at 2:22 PM, John Baldwin wrote: > >> >> >> > On Thursday, November 04, 2010 4:15:16 pm Hans Petter Selasky wrote: > >> >> >> >> I think that if a task is currently executing, then there > >> >> >> >> should be a drain method for that. I.E. two methods: One to > >> >> >> >> stop and one to cancel/drain. Can you implement this? > >> >> >> > > >> >> >> > I agree, this would also be consistent with the callout_*() API > >> >> >> > if you had both "stop()" and "drain()" methods. > >> >> >> > >> >> >> Here's my proposed code. Note that this builds but is not yet > >> >> >> tested. > >> >> >> > >> >> >> > >> >> >> Implement a taskqueue_cancel(9), to cancel a task from a queue. > >> >> >> > >> >> >> Requested by: hps > >> >> >> Original code: jeff > >> >> >> MFC after: 1 week > >> >> >> > >> >> >> > >> >> >> http://people.freebsd.org/~mdf/bsd-taskqueue-cancel.diff > >> >> > > >> >> > For FreeBSD taskqueue_cancel() should return EBUSY, not -EBUSY. > >> >> > However, I would prefer that it follow the semantics of > >> >> > callout_stop() and return true if it stopped the task and false > >> >> > otherwise. The Linux wrapper for taskqueue_cancel() can convert > >> >> > the return value. > >> >> > >> >> I used -EBUSY since positive return values reflect the old pending > >> >> count. ta_pending was zero'd, and I think needs to be to keep the > >> >> task sane, because all of taskqueue(9) assumes a non-zero ta_pending > >> >> means the task is queued. > >> >> > >> >> I don't know that the caller often needs to know the old value of > >> >> ta_pending, but it seems simpler to return that as the return value > >> >> and use -EBUSY than to use an optional pointer to a place to store > >> >> the old ta_pending just so we can keep the error return positive. > >> >> > >> >> Note that phk (IIRC) suggested using -error in the returns for > >> >> sbuf_drain to indicate the difference between success (> 0 bytes > >> >> drained) and an error, so FreeBSD now has precedent. I'm not > >> >> entirely sure that's a good thing, since I am not generally fond of > >> >> Linux's use of -error, but for some cases it is convenient. > >> >> > >> >> But, I'll do this one either way, just let me know if the above > >> >> hasn't convinced you. > >> > > >> > Hmm, I hadn't considered if callers would want to know the pending > >> > count of the cancelled task. > >> > > >> >> > I'm not sure I like reusing the memory allocation flags (M_NOWAIT / > >> >> > M_WAITOK) for this blocking flag. In the case of callout(9) we > >> >> > just have two functions that pass an internal boolean to the real > >> >> > routine (callout_stop() and callout_drain() are wrappers for > >> >> > _callout_stop_safe()). It is a bit unfortunate that > >> >> > taskqueue_drain() already exists and has different semantics than > >> >> > callout_drain(). It would have been nice to have the two APIs > >> >> > mirror each other instead. > >> >> > > >> >> > Hmm, I wonder if the blocking behavior cannot safely be provided by > >> >> > just doing: > >> >> > > >> >> > if (!taskqueue_cancel(queue, task, M_NOWAIT) > >> >> > taskqueue_drain(queue, task); > >> >> > >> >> This seems reasonable and correct. I will add a note to the manpage > >> >> about this. > >> > > >> > In that case, would you be fine with dropping the blocking > >> > functionality from taskqueue_cancel() completely and requiring code > >> > that wants the blocking semantics to use a cancel followed by a > >> > drain? > >> > >> New patch is at > >> http://people.freebsd.org/~mdf/0001-Implement-taskqueue_cancel-9-to-canc > >> el- a-task-from-a.patch > > > > I think the: > > > > + if (!task_is_running(queue, task)) { > > If it is running, it is dequeued from the the taskqueue, right? And while it is running it can be queued again, which your initial code didn't handle? --HPS From owner-freebsd-arch@FreeBSD.ORG Fri Nov 5 18:39:46 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 C989F1065674; Fri, 5 Nov 2010 18:39:46 +0000 (UTC) (envelope-from mdf356@gmail.com) Received: from mail-yx0-f182.google.com (mail-yx0-f182.google.com [209.85.213.182]) by mx1.freebsd.org (Postfix) with ESMTP id 448228FC13; Fri, 5 Nov 2010 18:39:45 +0000 (UTC) Received: by yxl31 with SMTP id 31so2477722yxl.13 for ; Fri, 05 Nov 2010 11:39:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=D29wDRntq2CSQZo7Nv6wTrGlpMMuFRkjaIAHLqmjLQA=; b=xF0WixRPSti32fB5rxhr9brs2sjVB9vN5YL0CFe3WDx4yvs/DEutQo6A2TmQ+QrwaD eQqzEASKZa+SQleMAlUKhLe3/iGQStfmXTfIpn0dXso9tRqyWxIbQTvYYXML3IW9+ItS aGAZOdBLnAJOdGHOe1dkabyMCPGJO+k2PgpcI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=WljFVibE0pGR8hNAZTYTdSu9rnEmS/16pWMhihuoVOHTeYxY4Ddh4sBoVNc4Fmxx+x 5dHW1z5YB6YEmWBNS9U4/JdPGAAON2nAfw6u9OqYijLS8XMitrp5AkYSP0vQRdNtR844 5MHJp6wS1/bBD/9jMPYUEBPdY32MYGCPdQxEI= MIME-Version: 1.0 Received: by 10.42.97.67 with SMTP id m3mr1524332icn.343.1288982385280; Fri, 05 Nov 2010 11:39:45 -0700 (PDT) Received: by 10.231.159.198 with HTTP; Fri, 5 Nov 2010 11:39:45 -0700 (PDT) In-Reply-To: <201011051935.27579.hselasky@c2i.net> References: <201011012054.59551.hselasky@c2i.net> <201011051836.39697.hselasky@c2i.net> <201011051935.27579.hselasky@c2i.net> Date: Fri, 5 Nov 2010 11:39:45 -0700 Message-ID: From: Matthew Fleming To: Hans Petter Selasky Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org, Weongyo Jeong , Andrew Thompson , freebsd-usb@freebsd.org, 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: Fri, 05 Nov 2010 18:39:46 -0000 On Fri, Nov 5, 2010 at 11:35 AM, Hans Petter Selasky wro= te: > On Friday 05 November 2010 19:13:08 Matthew Fleming wrote: >> On Fri, Nov 5, 2010 at 10:36 AM, Hans Petter Selasky > wrote: >> > On Friday 05 November 2010 18:15:01 Matthew Fleming wrote: >> >> On Fri, Nov 5, 2010 at 7:18 AM, John Baldwin wrote: >> >> > On Friday, November 05, 2010 9:50:10 am Matthew Fleming wrote: >> >> >> On Fri, Nov 5, 2010 at 5:58 AM, John Baldwin wro= te: >> >> >> > On Thursday, November 04, 2010 5:49:22 pm Matthew Fleming wrote: >> >> >> >> On Thu, Nov 4, 2010 at 2:22 PM, John Baldwin > wrote: >> >> >> >> > On Thursday, November 04, 2010 4:15:16 pm Hans Petter Selasky > wrote: >> >> >> >> >> I think that if a task is currently executing, then there >> >> >> >> >> should be a drain method for that. I.E. two methods: One to >> >> >> >> >> stop and one to cancel/drain. Can you implement this? >> >> >> >> > >> >> >> >> > I agree, this would also be consistent with the callout_*() A= PI >> >> >> >> > if you had both "stop()" and "drain()" methods. >> >> >> >> >> >> >> >> Here's my proposed code. =A0Note that this builds but is not ye= t >> >> >> >> tested. >> >> >> >> >> >> >> >> >> >> >> >> Implement a taskqueue_cancel(9), to cancel a task from a queue. >> >> >> >> >> >> >> >> Requested by: =A0 =A0 =A0 hps >> >> >> >> Original code: =A0 =A0 =A0jeff >> >> >> >> MFC after: =A01 week >> >> >> >> >> >> >> >> >> >> >> >> http://people.freebsd.org/~mdf/bsd-taskqueue-cancel.diff >> >> >> > >> >> >> > For FreeBSD taskqueue_cancel() should return EBUSY, not -EBUSY. >> >> >> > =A0However, I would prefer that it follow the semantics of >> >> >> > callout_stop() and return true if it stopped the task and false >> >> >> > otherwise. =A0The Linux wrapper for taskqueue_cancel() can conve= rt >> >> >> > the return value. >> >> >> >> >> >> I used -EBUSY since positive return values reflect the old pending >> >> >> count. =A0ta_pending was zero'd, and I think needs to be to keep t= he >> >> >> task sane, because all of taskqueue(9) assumes a non-zero ta_pendi= ng >> >> >> means the task is queued. >> >> >> >> >> >> I don't know that the caller often needs to know the old value of >> >> >> ta_pending, but it seems simpler to return that as the return valu= e >> >> >> and use -EBUSY than to use an optional pointer to a place to store >> >> >> the old ta_pending just so we can keep the error return positive. >> >> >> >> >> >> Note that phk (IIRC) suggested using -error in the returns for >> >> >> sbuf_drain to indicate the difference between success (> 0 bytes >> >> >> drained) and an error, so FreeBSD now has precedent. =A0I'm not >> >> >> entirely sure that's a good thing, since I am not generally fond o= f >> >> >> Linux's use of -error, but for some cases it is convenient. >> >> >> >> >> >> But, I'll do this one either way, just let me know if the above >> >> >> hasn't convinced you. >> >> > >> >> > Hmm, I hadn't considered if callers would want to know the pending >> >> > count of the cancelled task. >> >> > >> >> >> > I'm not sure I like reusing the memory allocation flags (M_NOWAI= T / >> >> >> > M_WAITOK) for this blocking flag. =A0In the case of callout(9) w= e >> >> >> > just have two functions that pass an internal boolean to the rea= l >> >> >> > routine (callout_stop() and callout_drain() are wrappers for >> >> >> > _callout_stop_safe()). =A0It is a bit unfortunate that >> >> >> > taskqueue_drain() already exists and has different semantics tha= n >> >> >> > callout_drain(). =A0It would have been nice to have the two APIs >> >> >> > mirror each other instead. >> >> >> > >> >> >> > Hmm, I wonder if the blocking behavior cannot safely be provided= by >> >> >> > just doing: >> >> >> > >> >> >> > =A0 =A0 =A0 =A0if (!taskqueue_cancel(queue, task, M_NOWAIT) >> >> >> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0taskqueue_drain(queue, task); >> >> >> >> >> >> This seems reasonable and correct. =A0I will add a note to the man= page >> >> >> about this. >> >> > >> >> > In that case, would you be fine with dropping the blocking >> >> > functionality from taskqueue_cancel() completely and requiring code >> >> > that wants the blocking semantics to use a cancel followed by a >> >> > drain? >> >> >> >> New patch is at >> >> http://people.freebsd.org/~mdf/0001-Implement-taskqueue_cancel-9-to-c= anc >> >> el- a-task-from-a.patch >> > >> > I think the: >> > >> > + =A0 =A0 =A0 if (!task_is_running(queue, task)) { >> > > > If it is running, it is dequeued from the the taskqueue, right? And while= it > is running it can be queued again, which your initial code didn't handle? True, but no taskqueue(9) code can handle that. Only the caller can prevent a task from becoming enqueued again. The same issue exists with taskqueue_drain(). BTW, I planned to commit the patch I sent today after testing, assuming jhb@ has no more issues. Thanks, matthew From owner-freebsd-arch@FreeBSD.ORG Fri Nov 5 18:44:45 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 5D12A106564A; Fri, 5 Nov 2010 18:44:45 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe06.swip.net [212.247.154.161]) by mx1.freebsd.org (Postfix) with ESMTP id 47BD58FC19; Fri, 5 Nov 2010 18:44:43 +0000 (UTC) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.1 cv=5UXFHLfkiY5XrCDma5uYm2T9fyMGz6t0cyN4hLfZsqg= c=1 sm=1 a=FberXtVRn-wA:10 a=8nJEP1OIZ-IA:10 a=CL8lFSKtTFcA:10 a=i9M/sDlu2rpZ9XS819oYzg==:17 a=Hn5bgWAfYFTdbKXFfdsA:9 a=2En-A4nSjAFEL4h1BRZjkSm4QfUA:4 a=wPNLvfGTeEIA:10 a=i9M/sDlu2rpZ9XS819oYzg==:117 Received: from [188.126.198.129] (account mc467741@c2i.net HELO laptop002.hselasky.homeunix.org) by mailfe06.swip.net (CommuniGate Pro SMTP 5.2.19) with ESMTPA id 44714363; Fri, 05 Nov 2010 19:44:42 +0100 From: Hans Petter Selasky To: freebsd-arch@freebsd.org Date: Fri, 5 Nov 2010 19:45:51 +0100 User-Agent: KMail/1.13.5 (FreeBSD/8.1-STABLE; KDE/4.4.5; amd64; ; ) References: <201011012054.59551.hselasky@c2i.net> <201011051935.27579.hselasky@c2i.net> In-Reply-To: X-Face: +~\`s("[*|O,="7?X@L.elg*F"OA\I/3%^p8g?ab%RN'( =?iso-8859-1?q?=3B=5FIjlA=3A=0A=09hGE=2E=2EEw?=, =?iso-8859-1?q?XAQ*o=23=5C/M=7ESC=3DS1-f9=7BEzRfT=27=7CHhll5Q=5Dha5Bt-s=7Co?= =?iso-8859-1?q?TlKMusi=3A1e=5BwJl=7Dkd=7DGR=0A=09Z0adGx-x=5F0zGbZj=27e?=(Y[(UNle~)8CQWXW@:DX+9)_YlB[tIccCPN$7/L' MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201011051945.51393.hselasky@c2i.net> Cc: freebsd-current@freebsd.org, Matthew Fleming , freebsd-usb@freebsd.org, Andrew Thompson , Weongyo Jeong 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: Fri, 05 Nov 2010 18:44:45 -0000 On Friday 05 November 2010 19:39:45 Matthew Fleming wrote: > True, but no taskqueue(9) code can handle that. Only the caller can > prevent a task from becoming enqueued again. The same issue exists > with taskqueue_drain(). I find that strange, because that means if I queue a task again while it is running, then I doesn't get run? Are you really sure? --HPS From owner-freebsd-arch@FreeBSD.ORG Fri Nov 5 18:48:06 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 C0B18106564A; Fri, 5 Nov 2010 18:48:06 +0000 (UTC) (envelope-from mdf356@gmail.com) Received: from mail-yw0-f54.google.com (mail-yw0-f54.google.com [209.85.213.54]) by mx1.freebsd.org (Postfix) with ESMTP id 37DF58FC20; Fri, 5 Nov 2010 18:48:05 +0000 (UTC) Received: by ywh2 with SMTP id 2so2519496ywh.13 for ; Fri, 05 Nov 2010 11:48:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=KkKNUrZJAdzo+uUSdLQ9ycvhki1H8jqlPpk2OKp8VME=; b=VaTx3IpJ/ApgbPCTxUeduldg5Du1ePvYOgX3M63B9hvANDSjlTcXc9A1zL0oUYZV+f S3RJeYAgDFots40uLm6kIpWZGkU2GYJ7MJL0iGTGybKF/U8HN+6CpqJf167X0+GldzdS Xv2qTGnwcSHXgMdQAaz657AnYt5DnyjThOLtE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=VE+PyPMPnqsTaDDlTO/p2JkkaBqAlP3fHzFlJa0/OQUn61a2Plp6/dgQQDIqVb036+ wJZKMIJG/6WQlHaJY6xbU8qNv2pMiQOnZ8tHK5SxEGd2LT+Fd5zvO0s4o3jrjROOO6Mw 9r+1HkSkO6bzY2TiMMyIg2lUMGfM5rs3Orgfs= MIME-Version: 1.0 Received: by 10.42.22.69 with SMTP id n5mr1388786icb.477.1288982885106; Fri, 05 Nov 2010 11:48:05 -0700 (PDT) Received: by 10.231.159.198 with HTTP; Fri, 5 Nov 2010 11:48:05 -0700 (PDT) In-Reply-To: <201011051945.51393.hselasky@c2i.net> References: <201011012054.59551.hselasky@c2i.net> <201011051935.27579.hselasky@c2i.net> <201011051945.51393.hselasky@c2i.net> Date: Fri, 5 Nov 2010 11:48:05 -0700 Message-ID: From: Matthew Fleming To: Hans Petter Selasky Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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: Fri, 05 Nov 2010 18:48:06 -0000 On Fri, Nov 5, 2010 at 11:45 AM, Hans Petter Selasky wro= te: > On Friday 05 November 2010 19:39:45 Matthew Fleming wrote: >> True, but no taskqueue(9) code can handle that. =A0Only the caller can >> prevent a task from becoming enqueued again. =A0The same issue exists >> with taskqueue_drain(). > > I find that strange, because that means if I queue a task again while it = is > running, then I doesn't get run? Are you really sure? If a task is currently running when enqueued, the task struct will be re-enqueued to the taskqueue. When that task comes up as the head of the queue, it will be run again. Thanks, matthew From owner-freebsd-arch@FreeBSD.ORG Fri Nov 5 18:59:31 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 87FD3106566B; Fri, 5 Nov 2010 18:59:31 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe01.swip.net [212.247.154.1]) by mx1.freebsd.org (Postfix) with ESMTP id 7F6878FC20; Fri, 5 Nov 2010 18:59:30 +0000 (UTC) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.1 cv=omSrwDgyMf70S47Fr5SNr0rQzcmIOo0IafWlB/wSLLo= c=1 sm=1 a=FberXtVRn-wA:10 a=8nJEP1OIZ-IA:10 a=CL8lFSKtTFcA:10 a=i9M/sDlu2rpZ9XS819oYzg==:17 a=8kQB0OdkAAAA:8 a=7l0j79IZqt8iMOdoQ2YA:9 a=f3QMjJQtTtU01tPy7UiD68_cvEMA:4 a=wPNLvfGTeEIA:10 a=9aOQ2cSd83gA:10 a=i9M/sDlu2rpZ9XS819oYzg==:117 Received: from [188.126.198.129] (account mc467741@c2i.net HELO laptop002.hselasky.homeunix.org) by mailfe01.swip.net (CommuniGate Pro SMTP 5.2.19) with ESMTPA id 45923574; Fri, 05 Nov 2010 19:59:28 +0100 From: Hans Petter Selasky To: freebsd-arch@freebsd.org Date: Fri, 5 Nov 2010 20:00:37 +0100 User-Agent: KMail/1.13.5 (FreeBSD/8.1-STABLE; KDE/4.4.5; amd64; ; ) References: <201011012054.59551.hselasky@c2i.net> <201011051945.51393.hselasky@c2i.net> In-Reply-To: X-Face: +~\`s("[*|O,="7?X@L.elg*F"OA\I/3%^p8g?ab%RN'( =?iso-8859-1?q?=3B=5FIjlA=3A=0A=09hGE=2E=2EEw?=, =?iso-8859-1?q?XAQ*o=23=5C/M=7ESC=3DS1-f9=7BEzRfT=27=7CHhll5Q=5Dha5Bt-s=7Co?= =?iso-8859-1?q?TlKMusi=3A1e=5BwJl=7Dkd=7DGR=0A=09Z0adGx-x=5F0zGbZj=27e?=(Y[(UNle~)8CQWXW@:DX+9)_YlB[tIccCPN$7/L' MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201011052000.37188.hselasky@c2i.net> Cc: freebsd-current@freebsd.org, Matthew Fleming , Andrew Thompson , freebsd-usb@freebsd.org, Weongyo Jeong 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: Fri, 05 Nov 2010 18:59:31 -0000 On Friday 05 November 2010 19:48:05 Matthew Fleming wrote: > On Fri, Nov 5, 2010 at 11:45 AM, Hans Petter Selasky wrote: > > On Friday 05 November 2010 19:39:45 Matthew Fleming wrote: > >> True, but no taskqueue(9) code can handle that. Only the caller can > >> prevent a task from becoming enqueued again. The same issue exists > >> with taskqueue_drain(). > > > > I find that strange, because that means if I queue a task again while it > > is running, then I doesn't get run? Are you really sure? > > If a task is currently running when enqueued, the task struct will be > re-enqueued to the taskqueue. When that task comes up as the head of > the queue, it will be run again. Right, and the taskqueue_cancel has to cancel in that state to, but it doesn't because it only checks pending if !running() :-) ?? --HPS From owner-freebsd-arch@FreeBSD.ORG Fri Nov 5 19:07:56 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 1B43A106566B; Fri, 5 Nov 2010 19:07:56 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id DB0298FC16; Fri, 5 Nov 2010 19:07:55 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 88C0F46B4C; Fri, 5 Nov 2010 15:07:55 -0400 (EDT) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 80B0E8A01D; Fri, 5 Nov 2010 15:07:54 -0400 (EDT) From: John Baldwin To: freebsd-arch@freebsd.org Date: Fri, 5 Nov 2010 15:06:12 -0400 User-Agent: KMail/1.13.5 (FreeBSD/7.3-CBSD-20100819; KDE/4.4.5; amd64; ; ) References: <201011012054.59551.hselasky@c2i.net> <201011052000.37188.hselasky@c2i.net> In-Reply-To: <201011052000.37188.hselasky@c2i.net> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201011051506.12643.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Fri, 05 Nov 2010 15:07:54 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.96.3 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-1.9 required=4.2 tests=BAYES_00 autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on bigwig.baldwin.cx Cc: Matthew Fleming , Andrew Thompson , Weongyo Jeong , freebsd-current@freebsd.org, freebsd-usb@freebsd.org, Hans Petter Selasky 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: Fri, 05 Nov 2010 19:07:56 -0000 On Friday, November 05, 2010 3:00:37 pm Hans Petter Selasky wrote: > On Friday 05 November 2010 19:48:05 Matthew Fleming wrote: > > On Fri, Nov 5, 2010 at 11:45 AM, Hans Petter Selasky > wrote: > > > On Friday 05 November 2010 19:39:45 Matthew Fleming wrote: > > >> True, but no taskqueue(9) code can handle that. Only the caller can > > >> prevent a task from becoming enqueued again. The same issue exists > > >> with taskqueue_drain(). > > > > > > I find that strange, because that means if I queue a task again while it > > > is running, then I doesn't get run? Are you really sure? > > > > If a task is currently running when enqueued, the task struct will be > > re-enqueued to the taskqueue. When that task comes up as the head of > > the queue, it will be run again. > > Right, and the taskqueue_cancel has to cancel in that state to, but it doesn't > because it only checks pending if !running() :-) ?? You can't close that race in taskqueue_cancel(). You have to manage that race yourself in your task handler. For the callout(9) API we are only able to close that race if you use callout_init_mtx() so that the code managing the callout wheel can make use of your lock to resolve the races. If you use callout_init() you have to explicitly manage these races in your callout handler. -- John Baldwin From owner-freebsd-arch@FreeBSD.ORG Sat Nov 6 08:36:46 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 5DD941065670; Sat, 6 Nov 2010 08:36:46 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe02.swip.net [212.247.154.33]) by mx1.freebsd.org (Postfix) with ESMTP id 23B178FC18; Sat, 6 Nov 2010 08:36:44 +0000 (UTC) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.1 cv=yevn+QCjI6xy199BDvBOOiO14qYvyLq62he9tTtU3M8= c=1 sm=1 a=FberXtVRn-wA:10 a=8nJEP1OIZ-IA:10 a=CL8lFSKtTFcA:10 a=i9M/sDlu2rpZ9XS819oYzg==:17 a=8kQB0OdkAAAA:8 a=NeL9HQIyaxTiqRflnoYA:9 a=Jzdrks91--tz73bWEW4A:7 a=b0ip0QWF_mfza3iejVZCFHj2lVUA:4 a=wPNLvfGTeEIA:10 a=9aOQ2cSd83gA:10 a=i9M/sDlu2rpZ9XS819oYzg==:117 Received: from [188.126.198.129] (account mc467741@c2i.net HELO laptop002.hselasky.homeunix.org) by mailfe02.swip.net (CommuniGate Pro SMTP 5.2.19) with ESMTPA id 45442018; Sat, 06 Nov 2010 09:36:42 +0100 From: Hans Petter Selasky To: freebsd-arch@freebsd.org Date: Sat, 6 Nov 2010 09:37:50 +0100 User-Agent: KMail/1.13.5 (FreeBSD/8.1-STABLE; KDE/4.4.5; amd64; ; ) References: <201011012054.59551.hselasky@c2i.net> <201011052000.37188.hselasky@c2i.net> <201011051506.12643.jhb@freebsd.org> In-Reply-To: <201011051506.12643.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-1" Content-Transfer-Encoding: 7bit Message-Id: <201011060937.50639.hselasky@c2i.net> Cc: Matthew Fleming , Andrew Thompson , Weongyo Jeong , freebsd-current@freebsd.org, freebsd-usb@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: Sat, 06 Nov 2010 08:36:46 -0000 On Friday 05 November 2010 20:06:12 John Baldwin wrote: > On Friday, November 05, 2010 3:00:37 pm Hans Petter Selasky wrote: > > On Friday 05 November 2010 19:48:05 Matthew Fleming wrote: > > > On Fri, Nov 5, 2010 at 11:45 AM, Hans Petter Selasky > > > > wrote: > > > > On Friday 05 November 2010 19:39:45 Matthew Fleming wrote: > > > >> True, but no taskqueue(9) code can handle that. Only the caller can > > > >> prevent a task from becoming enqueued again. The same issue exists > > > >> with taskqueue_drain(). > > > > > > > > I find that strange, because that means if I queue a task again while > > > > it is running, then I doesn't get run? Are you really sure? > > > > > > If a task is currently running when enqueued, the task struct will be > > > re-enqueued to the taskqueue. When that task comes up as the head of > > > the queue, it will be run again. > > > > Right, and the taskqueue_cancel has to cancel in that state to, but it > > doesn't because it only checks pending if !running() :-) ?? > > You can't close that race in taskqueue_cancel(). You have to manage that > race yourself in your task handler. For the callout(9) API we are only > able to close that race if you use callout_init_mtx() so that the code > managing the callout wheel can make use of your lock to resolve the races. > If you use callout_init() you have to explicitly manage these races in your > callout handler. Hi, I think you are getting me wrong! In the initial "0001-Implement- taskqueue_cancel-9-to-cancel-a-task-from-a.patch" you have the following code- chunk: +int +taskqueue_cancel(struct taskqueue *queue, struct task *task) +{ + int rc; + + TQ_LOCK(queue); + if (!task_is_running(queue, task)) { + if ((rc = task->ta_pending) > 0) + STAILQ_REMOVE(&queue->tq_queue, task, task, ta_link); + task->ta_pending = 0; + } else + rc = -EBUSY; + TQ_UNLOCK(queue); + return (rc); +} This code should be written like this, having the if (!task_is_running()) after checking the ta_pending variable. +int +taskqueue_cancel(struct taskqueue *queue, struct task *task) +{ + int rc; + + TQ_LOCK(queue); + if ((rc = task->ta_pending) > 0) { + STAILQ_REMOVE(&queue->tq_queue, task, task, ta_link); + task->ta_pending = 0; + } + if (!task_is_running(queue, task)) + rc = -EBUSY; + TQ_UNLOCK(queue); + return (rc); +} Or completely skip the !task_is_running() check. Else you are opening up a race in this function! Do I need to explain that more? Isn't it obvious? --HPS From owner-freebsd-arch@FreeBSD.ORG Sat Nov 6 11:39:34 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 883FF1065670 for ; Sat, 6 Nov 2010 11:39:34 +0000 (UTC) (envelope-from gljennjohn@googlemail.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 0D30E8FC08 for ; Sat, 6 Nov 2010 11:39:33 +0000 (UTC) Received: by bwz3 with SMTP id 3so3428384bwz.13 for ; Sat, 06 Nov 2010 04:39:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:date:from:to:cc:subject :message-id:in-reply-to:references:reply-to:x-mailer:mime-version :content-type:content-transfer-encoding; bh=dFn+5EGEuAAQGfEzw5N63eCQnGz83cx2lSqRQUogxhM=; b=HUnQzPbfbhGnuxWC71DCkvf2E+VJmO8VQSln70HMYIP8CeJkr1HG00KgwhEuuIcZLC TcwiA7mFmJsSTLxwrOHTLiScYC4jUM1NK0bFUZz3UVo1twWFXsqkjmDnxvmB91y0TqAe JsSAB7VUYsKoShlZpFc3raiMaLhxppSndJ1gA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=date:from:to:cc:subject:message-id:in-reply-to:references:reply-to :x-mailer:mime-version:content-type:content-transfer-encoding; b=gpeLfeDDSkiwTOLbF6IHFj3Z1K2lb1JJ7XOgil17U3/TaJV/llb7VgQsubUXhLrLZH tzJ6ZJyAx/QRLVeOg3NIO2FATNfrUKu9tJyzIYeQ3aDiiWgJRAwBSEnsK/ImYYRYYEH0 gkcqwcmnc5CTiPG5NeEacBeBJKo5R/dRyOXEc= Received: by 10.204.117.2 with SMTP id o2mr2831421bkq.69.1289041676129; Sat, 06 Nov 2010 04:07:56 -0700 (PDT) Received: from ernst.jennejohn.org (p578E3053.dip.t-dialin.net [87.142.48.83]) by mx.google.com with ESMTPS id g8sm1853695bkg.23.2010.11.06.04.07.54 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 06 Nov 2010 04:07:54 -0700 (PDT) Date: Sat, 6 Nov 2010 12:07:52 +0100 From: Gary Jennejohn To: Baptiste Daroussin Message-ID: <20101106120752.001e92c0@ernst.jennejohn.org> In-Reply-To: References: X-Mailer: Claws Mail 3.7.6 (GTK+ 2.18.7; amd64-portbld-freebsd9.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-arch@freebsd.org Subject: Re: [PATCH] update to the latest libedit version and remove libreadline deps X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: gljennjohn@googlemail.com List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Nov 2010 11:39:34 -0000 On Fri, 5 Nov 2010 16:58:55 +0100 Baptiste Daroussin wrote: > Hi, > > I have been told that this list is betted suited for that kind of patches. > > regards, > Bapt > > > ---------- Forwarded message ---------- > From: Baptiste Daroussin > Date: 2010/11/5 > Subject: [PATCH] update to the latest libedit version and remove > libreadline deps > To: freebsd-hackers@freebsd.org > > > Hi all, > > I've updated libedit to the latest version available in the netbsd cvs. > UTF8 support is disabled for now has it seems to be experimental and segfault. > I also patch and tested all the sources that used to be linked against > libreadline so that it now uses libedit making libreadline unused (I > guess, perhaps I have missed some) > > beware that there are collision between libreadline and libedit > (/usr/include/readline/readline.h) is provided by both of them. > > You can find the patch against current here: > http://people.freebsd.org/~bapt/update-libedit.patch > contrib/wpa/wpa_supplicant/wpa_cli.c, lib/libdisk/tst01.c and sbin/gvinum/gvinum.c include stuff from readline. These are all still in SVN. -- Gary Jennejohn From owner-freebsd-arch@FreeBSD.ORG Sat Nov 6 13:57:51 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 537641065670; Sat, 6 Nov 2010 13:57:51 +0000 (UTC) (envelope-from mdf356@gmail.com) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id E05B28FC0C; Sat, 6 Nov 2010 13:57:50 +0000 (UTC) Received: by iwn39 with SMTP id 39so4024936iwn.13 for ; Sat, 06 Nov 2010 06:57:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=qneazsDNIHnT+FEsdzd/Vc6yhd1g6m4aAkCjeGHIAMw=; b=CFnhB3cCkSNfelW8UcFuxLarlS+3zZMlijDET3vxNkRySt9ibcgHRpjS7Om4X1K7/5 WR+P4/a1SOSG+F+qySywBouVWukTQfSpZarFVoXYlRR+vsxdXishRDf7Y11mFxC4xPbR BTt29+FPoWyra4/37TfiTOi2M/F2gJZ0YXSmE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=oZco27Wbk68/LY9YVT6k3pPpaQecIFIYOS9uT5ZdHrvfkRyXG7sYDcdWRuUUOSlgf+ ySk7pJPZh4nIrArxFMh36HqbQbgFkAWw3cqhpo3ZOnCurV1Lzcj5z8bC270IyWFeuX7p wC+EPwA8+NSTFkaxSnq9AKLOPb0ShcubMGC8c= MIME-Version: 1.0 Received: by 10.231.35.138 with SMTP id p10mr2659573ibd.33.1289051870364; Sat, 06 Nov 2010 06:57:50 -0700 (PDT) Received: by 10.231.159.198 with HTTP; Sat, 6 Nov 2010 06:57:50 -0700 (PDT) In-Reply-To: <201011060937.50639.hselasky@c2i.net> References: <201011012054.59551.hselasky@c2i.net> <201011052000.37188.hselasky@c2i.net> <201011051506.12643.jhb@freebsd.org> <201011060937.50639.hselasky@c2i.net> Date: Sat, 6 Nov 2010 06:57:50 -0700 Message-ID: From: Matthew Fleming To: Hans Petter Selasky Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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: Sat, 06 Nov 2010 13:57:51 -0000 On Sat, Nov 6, 2010 at 1:37 AM, Hans Petter Selasky wrot= e: > On Friday 05 November 2010 20:06:12 John Baldwin wrote: >> On Friday, November 05, 2010 3:00:37 pm Hans Petter Selasky wrote: >> > On Friday 05 November 2010 19:48:05 Matthew Fleming wrote: >> > > On Fri, Nov 5, 2010 at 11:45 AM, Hans Petter Selasky >> > >> > wrote: >> > > > On Friday 05 November 2010 19:39:45 Matthew Fleming wrote: >> > > >> True, but no taskqueue(9) code can handle that. =A0Only the calle= r can >> > > >> prevent a task from becoming enqueued again. =A0The same issue ex= ists >> > > >> with taskqueue_drain(). >> > > > >> > > > I find that strange, because that means if I queue a task again wh= ile >> > > > it is running, then I doesn't get run? Are you really sure? >> > > >> > > If a task is currently running when enqueued, the task struct will b= e >> > > re-enqueued to the taskqueue. =A0When that task comes up as the head= of >> > > the queue, it will be run again. >> > >> > Right, and the taskqueue_cancel has to cancel in that state to, but it >> > doesn't because it only checks pending if !running() :-) ?? >> >> You can't close that race in taskqueue_cancel(). =A0You have to manage t= hat >> race yourself in your task handler. =A0For the callout(9) API we are onl= y >> able to close that race if you use callout_init_mtx() so that the code >> managing the callout wheel can make use of your lock to resolve the race= s. >> If you use callout_init() you have to explicitly manage these races in y= our >> callout handler. > > Hi, > > I think you are getting me wrong! In the initial "0001-Implement- > taskqueue_cancel-9-to-cancel-a-task-from-a.patch" you have the following = code- > chunk: > > +int > +taskqueue_cancel(struct taskqueue *queue, struct task *task) > +{ > + =A0 =A0 =A0 int rc; > + > + =A0 =A0 =A0 TQ_LOCK(queue); > + =A0 =A0 =A0 if (!task_is_running(queue, task)) { > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 if ((rc =3D task->ta_pending) > 0) > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 STAILQ_REMOVE(&queue->tq_qu= eue, task, task, ta_link); > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 task->ta_pending =3D 0; > + =A0 =A0 =A0 } else > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 rc =3D -EBUSY; > + =A0 =A0 =A0 TQ_UNLOCK(queue); > + =A0 =A0 =A0 return (rc); > +} > > This code should be written like this, having the if (!task_is_running()) > after checking the ta_pending variable. > > +int > +taskqueue_cancel(struct taskqueue *queue, struct task *task) > +{ > + =A0 =A0 =A0 int rc; > + > + =A0 =A0 =A0 TQ_LOCK(queue); > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 if ((rc =3D task->ta_pending) > 0) { > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 STAILQ_REMOVE(&queue->tq_qu= eue, task, task, ta_link); > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 task->t= a_pending =3D 0; > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 } > + =A0 =A0 =A0 if (!task_is_running(queue, task)) > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 rc =3D -EBUSY; > + =A0 =A0 =A0 TQ_UNLOCK(queue); > + =A0 =A0 =A0 return (rc); > +} > > Or completely skip the !task_is_running() check. Else you are opening up = a > race in this function! Do I need to explain that more? Isn't it obvious? I think you're misunderstanding the existing taskqueue(9) implementation. As long as TQ_LOCK is held, the state of ta->ta_pending cannot change, nor can the set of running tasks. So the order of checks is irrelevant. As John said, the taskqueue(9) implementation cannot protect consumers of it from re-queueing a task; that kind of serialization needs to happen at a higher level. taskqueue(9) is not quite like callout(9); the taskqueue(9) implementation drops all locks before calling the task's callback function. So once the task is running, taskqueue(9) can do nothing about it until the task stops running. This is why Jeff's implementation of taskqueue_cancel(9) slept if the task was running, and why mine returns an error code. The only way to know for sure that a task is "about" to run is to ask taskqueue(9), because there's a window where the TQ_LOCK is dropped before the callback is entered. Thanks, matthew From owner-freebsd-arch@FreeBSD.ORG Sat Nov 6 14:21:22 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 4D0D01065673; Sat, 6 Nov 2010 14:21:22 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe03.swip.net [212.247.154.65]) by mx1.freebsd.org (Postfix) with ESMTP id 4673E8FC0A; Sat, 6 Nov 2010 14:21:20 +0000 (UTC) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.1 cv=iBCGAMPDYtSF9sDXX85uHY3wcnYctfVT8vFpe3qPflY= c=1 sm=1 a=FberXtVRn-wA:10 a=8nJEP1OIZ-IA:10 a=CL8lFSKtTFcA:10 a=i9M/sDlu2rpZ9XS819oYzg==:17 a=Z_5cUCg6Vf7GDme7dpcA:9 a=Ucnf10t7tCBU3dq19hQA:7 a=7vaHduFuufULc36w12w6ebi1-I0A:4 a=wPNLvfGTeEIA:10 a=i9M/sDlu2rpZ9XS819oYzg==:117 Received: from [188.126.198.129] (account mc467741@c2i.net HELO laptop002.hselasky.homeunix.org) by mailfe03.swip.net (CommuniGate Pro SMTP 5.2.19) with ESMTPA id 45604739; Sat, 06 Nov 2010 15:21:19 +0100 From: Hans Petter Selasky To: freebsd-arch@freebsd.org Date: Sat, 6 Nov 2010 15:22:26 +0100 User-Agent: KMail/1.13.5 (FreeBSD/8.1-STABLE; KDE/4.4.5; amd64; ; ) References: <201011012054.59551.hselasky@c2i.net> <201011060937.50639.hselasky@c2i.net> In-Reply-To: X-Face: +~\`s("[*|O,="7?X@L.elg*F"OA\I/3%^p8g?ab%RN'( =?iso-8859-1?q?=3B=5FIjlA=3A=0A=09hGE=2E=2EEw?=, =?iso-8859-1?q?XAQ*o=23=5C/M=7ESC=3DS1-f9=7BEzRfT=27=7CHhll5Q=5Dha5Bt-s=7Co?= =?iso-8859-1?q?TlKMusi=3A1e=5BwJl=7Dkd=7DGR=0A=09Z0adGx-x=5F0zGbZj=27e?=(Y[(UNle~)8CQWXW@:DX+9)_YlB[tIccCPN$7/L' MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201011061522.26533.hselasky@c2i.net> Cc: freebsd-current@freebsd.org, Matthew Fleming , Andrew Thompson , freebsd-usb@freebsd.org, Weongyo Jeong 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: Sat, 06 Nov 2010 14:21:22 -0000 Hi, On Saturday 06 November 2010 14:57:50 Matthew Fleming wrote: > > I think you're misunderstanding the existing taskqueue(9) implementation. > > As long as TQ_LOCK is held, the state of ta->ta_pending cannot change, > nor can the set of running tasks. So the order of checks is > irrelevant. I agree that the order of checks is not important. That is not the problem. Cut & paste from suggested taskqueue patch from Fleming: > +int > > +taskqueue_cancel(struct taskqueue *queue, struct task *task) > > +{ > > + int rc; > > + > > + TQ_LOCK(queue); > > + if (!task_is_running(queue, task)) { > > + if ((rc = task->ta_pending) > 0) > > + STAILQ_REMOVE(&queue->tq_queue, task, task, > > ta_link); + task->ta_pending = 0; > > + } else { > > + rc = -EBUSY; What happens in this case if ta_pending > 0. Are you saying this is not possible? If ta_pending > 0, shouldn't we also do a STAILQ_REMOVE() ? > > + } > > + TQ_UNLOCK(queue); > > + return (rc); > > +} > > > As John said, the taskqueue(9) implementation cannot protect consumers > of it from re-queueing a task; that kind of serialization needs to > happen at a higher level. Agreed, but that is not what I'm pointing at. I'm pointing at what happens if you re-queue a task and then cancel while it is actually running. Will the task still be queued for execution after taskqueue_cancel()? > taskqueue(9) is not quite like callout(9); the taskqueue(9) > implementation drops all locks before calling the task's callback > function. So once the task is running, taskqueue(9) can do nothing > about it until the task stops running. This is not the problem. > > This is why Jeff's > implementation of taskqueue_cancel(9) slept if the task was running, > and why mine returns an error code. The only way to know for sure > that a task is "about" to run is to ask taskqueue(9), because there's > a window where the TQ_LOCK is dropped before the callback is entered. And if you re-queue and cancel in this window, shouldn't this also be handled like in the other cases? Cut & paste from kern/subr_taskqueue.c: task->ta_pending = 0; tb.tb_running = task; TQ_UNLOCK(queue); If a concurrent thread at exactly this point in time calls taskqueue_enqueue() on this task, then we re-add the task to the "queue->tq_queue". So far we agree. Imagine now that for some reason a following call to taskqueue_cancel() on this task at same point in time. Now, shouldn't taskqueue_cancel() also remove the task from the "queue->tq_queue" in this case aswell? Because in your implementation you only remove the task if we are not running, and that is not true when we are at exactly this point in time. task->ta_func(task->ta_context, pending); TQ_LOCK(queue); tb.tb_running = NULL; wakeup(task); Another issue I noticed is that the ta_pending counter should have a wrap protector. --HPS From owner-freebsd-arch@FreeBSD.ORG Sat Nov 6 15:31:39 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 988C21065694 for ; Sat, 6 Nov 2010 15:31:39 +0000 (UTC) (envelope-from swell.k@gmail.com) Received: from mail-ew0-f54.google.com (mail-ew0-f54.google.com [209.85.215.54]) by mx1.freebsd.org (Postfix) with ESMTP id 229B58FC1B for ; Sat, 6 Nov 2010 15:31:38 +0000 (UTC) Received: by ewy28 with SMTP id 28so2315978ewy.13 for ; Sat, 06 Nov 2010 08:31:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:cc:subject:references :date:in-reply-to:message-id:user-agent:mime-version:content-type; bh=Xb7REWXttL9gFrnkm6xftkkAXDMon0k7Mnw/y7IQnSw=; b=nrcKgqr0WveoLPs1BrBhOR7bEPOUgroRKTqbRgMVfgRnT+6EyANo/GOQXe7ycaveo/ esqTdGlFuLOqiNi/wvq3n2Zx0cRVcJaL8qxbGsaJV9ErhqCKDOVCu3OEUDrSFeVWCPYc WQGOIjrM6dWqqhhUGticNWuMrBwBEYzJ1hFy0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version:content-type; b=EwjB44Hu0hWf4diSfNcBSXLqGJ93MH2Xep3z7eAmnnrQAPZcwWjoNIf3RjadvlxMoC qnv1z8Bjae/fb40W5UGWgNeL26aUuffcXvUFASgq9B4JhPD4rPsaFlY4OxBbZre6VcGx FrS0bOLaFt1XFV4Qy9uJYuaMiNzJPZ69sxZJc= Received: by 10.14.47.69 with SMTP id s45mr1798837eeb.12.1289055831064; Sat, 06 Nov 2010 08:03:51 -0700 (PDT) Received: from localhost (tor-exit-proxy4-readme.formlessnetworking.net [208.53.142.40]) by mx.google.com with ESMTPS id q58sm2209717eeh.3.2010.11.06.08.03.47 (version=SSLv3 cipher=RC4-MD5); Sat, 06 Nov 2010 08:03:49 -0700 (PDT) From: Anonymous To: gljennjohn@googlemail.com References: <20101106120752.001e92c0@ernst.jennejohn.org> Date: Sat, 06 Nov 2010 18:03:39 +0300 In-Reply-To: <20101106120752.001e92c0@ernst.jennejohn.org> (Gary Jennejohn's message of "Sat, 6 Nov 2010 12:07:52 +0100") Message-ID: <86vd4ao5o4.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain Cc: Baptiste Daroussin , freebsd-arch@freebsd.org Subject: Re: [PATCH] update to the latest libedit version and remove libreadline deps 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: Sat, 06 Nov 2010 15:31:39 -0000 Gary Jennejohn writes: > On Fri, 5 Nov 2010 16:58:55 +0100 > Baptiste Daroussin wrote: >> I've updated libedit to the latest version available in the netbsd cvs. >> UTF8 support is disabled for now has it seems to be experimental and segfault. >> I also patch and tested all the sources that used to be linked against >> libreadline so that it now uses libedit making libreadline unused (I >> guess, perhaps I have missed some) >> >> beware that there are collision between libreadline and libedit >> (/usr/include/readline/readline.h) is provided by both of them. >> >> You can find the patch against current here: >> http://people.freebsd.org/~bapt/update-libedit.patch >> > > contrib/wpa/wpa_supplicant/wpa_cli.c, lib/libdisk/tst01.c and > sbin/gvinum/gvinum.c include stuff from readline. > > These are all still in SVN. I think all those hunks in the patch removing are unnecessary. On NetBSD history.h is a symlink to readline.h according to libedit/readline/Makefile: INCS= readline.h INCSYMLINKS= readline.h ${INCSDIR}/history.h So, try to replace INCSYMLINKS with INCSLINKS. From owner-freebsd-arch@FreeBSD.ORG Sat Nov 6 20:33:18 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 CC9EE10656C6; Sat, 6 Nov 2010 20:33:18 +0000 (UTC) (envelope-from mdf356@gmail.com) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 564398FC16; Sat, 6 Nov 2010 20:33:18 +0000 (UTC) Received: by iwn39 with SMTP id 39so4326861iwn.13 for ; Sat, 06 Nov 2010 13:33:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=teNB6EWR4XSnmTt3IQoFlxO0MPxY61lmOqo/4Vkkkyk=; b=QTPkZSxRVgIYuRNmcl7zm56VSwA4YHsYGLkAP5Zzxm+YGUV/JVgdkFox80Bm/5yitN a/4cjz6vRUTotF5kTuXrvWzK/ySR0YG5SnMPyJyDechgFruwITZ+ZED5bzsBbxyxXURV +6vVA6Gc13Pz4XAt0FsIwC3g8eQapIR0rs84c= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=HWJfT8+AdVD0tLl39v1yLP18AHJVCW2vEYrNUvQ393LQs+u8rJ9kEdYvdAhcjs3ysK G5Xcw5iBokYD3B7250ZWO0AnkFD/YsjUSZDG590duV3E//kR03mesaVn3XAvnWmnklJN r0hx8VDZ4LW/wMs7x/8YC2UzUHGBvTFrKZOGA= MIME-Version: 1.0 Received: by 10.42.97.67 with SMTP id m3mr502601icn.343.1289075597669; Sat, 06 Nov 2010 13:33:17 -0700 (PDT) Received: by 10.231.159.198 with HTTP; Sat, 6 Nov 2010 13:33:17 -0700 (PDT) In-Reply-To: <201011061522.26533.hselasky@c2i.net> References: <201011012054.59551.hselasky@c2i.net> <201011060937.50639.hselasky@c2i.net> <201011061522.26533.hselasky@c2i.net> Date: Sat, 6 Nov 2010 13:33:17 -0700 Message-ID: From: Matthew Fleming To: Hans Petter Selasky , John Baldwin Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org, Weongyo Jeong , Andrew Thompson , freebsd-usb@freebsd.org, 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: Sat, 06 Nov 2010 20:33:18 -0000 On Sat, Nov 6, 2010 at 7:22 AM, Hans Petter Selasky wrot= e: > Hi, > > On Saturday 06 November 2010 14:57:50 Matthew Fleming wrote: >> >> I think you're misunderstanding the existing taskqueue(9) implementation= . >> >> As long as TQ_LOCK is held, the state of ta->ta_pending cannot change, >> nor can the set of running tasks. =A0So the order of checks is >> irrelevant. > > I agree that the order of checks is not important. That is not the proble= m. > > Cut & paste from suggested taskqueue patch from Fleming: > > =A0> +int >> > +taskqueue_cancel(struct taskqueue *queue, struct task *task) >> > +{ >> > + =A0 =A0 =A0 int rc; >> > + >> > + =A0 =A0 =A0 TQ_LOCK(queue); >> > + =A0 =A0 =A0 if (!task_is_running(queue, task)) { >> > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 if ((rc =3D task->ta_pending) > 0) >> > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 STAILQ_REMOVE(&queue->tq= _queue, task, task, >> > ta_link); + =A0 =A0 =A0 =A0 =A0 =A0 =A0 task->ta_pending =3D 0; >> > + =A0 =A0 =A0 } else { >> > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 rc =3D -EBUSY; > > What happens in this case if ta_pending > 0. Are you saying this is not > possible? If ta_pending > 0, shouldn't we also do a STAILQ_REMOVE() ? Ah! I see what you mean. I'm not quite sure what the best thing to do here is; I agree it would be nice if taskqueue_cancel(9) dequeued the task, but I believe it also needs to indicate that the task is currently running. I guess the best thing would be to return the old pending count by reference parameter, and 0 or EBUSY to also indicate if there is a task currently running. Adding jhb@ to this mail since he has good thoughts on interfacing. Thanks, matthew > >> > + =A0 =A0 =A0 } >> > + =A0 =A0 =A0 TQ_UNLOCK(queue); >> > + =A0 =A0 =A0 return (rc); >> > +} >> > >> >> As John said, the taskqueue(9) implementation cannot protect consumers >> of it from re-queueing a task; that kind of serialization needs to >> happen at a higher level. > > Agreed, but that is not what I'm pointing at. I'm pointing at what happen= s if > you re-queue a task and then cancel while it is actually running. Will th= e > task still be queued for execution after taskqueue_cancel()? > >> taskqueue(9) is not quite like callout(9); the taskqueue(9) >> implementation drops all locks before calling the task's callback >> function. =A0So once the task is running, taskqueue(9) can do nothing >> about it until the task stops running. > > This is not the problem. > >> >> This is why Jeff's >> implementation of taskqueue_cancel(9) slept if the task was running, >> and why mine returns an error code. =A0The only way to know for sure >> that a task is "about" to run is to ask taskqueue(9), because there's >> a window where the TQ_LOCK is dropped before the callback is entered. > > And if you re-queue and cancel in this window, shouldn't this also be han= dled > like in the other cases? > > Cut & paste from kern/subr_taskqueue.c: > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0task->ta_pending =3D 0; > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0tb.tb_running =3D task; > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0TQ_UNLOCK(queue); > > If a concurrent thread at exactly this point in time calls taskqueue_enqu= eue() > on this task, then we re-add the task to the "queue->tq_queue". So far we > agree. Imagine now that for some reason a following call to taskqueue_can= cel() > on this task at same point in time. Now, shouldn't taskqueue_cancel() als= o > remove the task from the "queue->tq_queue" in this case aswell? Because i= n > your implementation you only remove the task if we are not running, and t= hat > is not true when we are at exactly this point in time. > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0task->ta_func(task->ta_context, pending); > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0TQ_LOCK(queue); > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0tb.tb_running =3D NULL; > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0wakeup(task); > > > Another issue I noticed is that the ta_pending counter should have a wrap > protector. > > --HPS >