From owner-freebsd-performance@FreeBSD.ORG Sun Nov 30 20:26:25 2008 Return-Path: Delivered-To: freebsd-performance@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7B837106564A for ; Sun, 30 Nov 2008 20:26:25 +0000 (UTC) (envelope-from gofp-freebsd-performance@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.freebsd.org (Postfix) with ESMTP id F41AD8FC12 for ; Sun, 30 Nov 2008 20:26:24 +0000 (UTC) (envelope-from gofp-freebsd-performance@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1L6ss3-0007YX-7F for freebsd-performance@freebsd.org; Sun, 30 Nov 2008 20:26:23 +0000 Received: from 93-138-125-188.adsl.net.t-com.hr ([93.138.125.188]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 30 Nov 2008 20:26:23 +0000 Received: from ivoras by 93-138-125-188.adsl.net.t-com.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 30 Nov 2008 20:26:23 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-performance@freebsd.org From: Ivan Voras Date: Sun, 30 Nov 2008 21:25:59 +0100 Lines: 52 Message-ID: References: <492B3E3E.1000001@softhammer.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig410B2DB8F0B166CEADBBBF9B" X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 93-138-125-188.adsl.net.t-com.hr User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) In-Reply-To: <492B3E3E.1000001@softhammer.net> X-Enigmail-Version: 0.95.7 Sender: news Cc: freebsd-questions@freebsd.org Subject: Re: boot loader bug??? X-BeenThere: freebsd-performance@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Performance/tuning List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Nov 2008 20:26:25 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig410B2DB8F0B166CEADBBBF9B Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Stephen Sanders wrote: > This may be a bad list to post to for this problem but I'm having an > issue where in it appears that the boot loader fails and then overwrite= s > the MBR with 0. >=20 > The system boots to : >=20 > F1 - Linux > F3 - FreeBSD > F5 - Drive 1" >=20 > Default: >=20 > But then fails on "boot error". Rebooting will not even make it to the= > prompt above and if one checks the MBR (via a PXE boot), it has been se= t > to 512 bytes of 0. >=20 > Sound familiar? Thanks This is definitely not the right list for your question. Please take it to questions@. There has been one report that points out that some broken BIOSes change disk IDs after booting so that the loader overwrites the boot sector on the wrong disc, but this doesn't look like it's applicable to your problem. You can disable MBR modification by the boot loader with the "noupdate" options to boot0cfg(8). --------------enig410B2DB8F0B166CEADBBBF9B Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkky9tcACgkQldnAQVacBchSxACfdDQUkdeIkfBl3I4H759j9CcU y70AoKRVniHF0sjbtbkKPgcf+h9O76JO =CZ06 -----END PGP SIGNATURE----- --------------enig410B2DB8F0B166CEADBBBF9B-- From owner-freebsd-performance@FreeBSD.ORG Wed Dec 3 11:10:12 2008 Return-Path: Delivered-To: freebsd-performance@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1AEBF1065676 for ; Wed, 3 Dec 2008 11:10:12 +0000 (UTC) (envelope-from gofp-freebsd-performance@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.freebsd.org (Postfix) with ESMTP id 9623F8FC18 for ; Wed, 3 Dec 2008 11:10:11 +0000 (UTC) (envelope-from gofp-freebsd-performance@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1L7pcL-00006K-Vz for freebsd-performance@freebsd.org; Wed, 03 Dec 2008 11:10:05 +0000 Received: from 195.208.174.178 ([195.208.174.178]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 03 Dec 2008 11:10:05 +0000 Received: from vadim_nuclight by 195.208.174.178 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 03 Dec 2008 11:10:05 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-performance@freebsd.org From: Vadim Goncharov Date: Wed, 3 Dec 2008 11:09:58 +0000 (UTC) Organization: Nuclear Lightning @ Tomsk, TPU AVTF Hostel Lines: 57 Message-ID: References: X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 195.208.174.178 X-Comment-To: Adrian Chadd User-Agent: slrn/0.9.8.1 (FreeBSD) Sender: news Subject: Re: hwpmc granularity and 6.4 network performance X-BeenThere: freebsd-performance@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: vadim_nuclight@mail.ru List-Id: Performance/tuning List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Dec 2008 11:10:12 -0000 Hi Adrian Chadd! On Tue, 25 Nov 2008 15:09:19 -0500; Adrian Chadd wrote about 'Re: hwpmc granularity and 6.4 network performance': > * Since you've changed two things - hwpmc _AND_ the kernel version - > you can't easily conclude which one (if any!) has any influence on > Giant showing up in your top output. I suggest recompiling without > hwpmc and seeing if the behaviour changes. This is not so easy to do at the time when I want :) I will check this some weeks later, may be. > * The gprof utility expects something resembling "time" for the > sampling data, but pmcstat doesn't record time, it records "events". > The counts you see in gprof are "events", so change "seconds" to > "events" in your reading of the gprof output. Of course, I know this, but it doesn't change the percentage. > * I don't know if the backported pmc to 6.4 handles stack call graphs > or not. Easy way to check - pmcstat -R sample.out | more ; see if you > just see "sample" lines or "sample" and "callgraph" lines. No. > * I bet that ipfw_chk is a big enough hint. How big is your ipfw ruleset? :) It's not so big in terms of rule count and not so big in terms of exact hint, but it is of course big as a CPU hog :) router# ipfw show | wc -l 70 Surely, not so much, yes? So I want to see which parts are more CPU-intensive, to use as a hint when rewriting ruleset. I've heard about a pmcannotate tool, in -arch@, and I think that it is tool which does the thing exactly what I want, but that requires patch for pmcstat which didn't apply on my 6.4, too much was different :( >> OK, I can conclude from this that I should optimize my ipfw ruleset, but >> that's all. I know from sources that ipfw_chk() is a big function with a >> bunch of 'case's in a large 'switch'. I want to know which parts of that >> switch are executed more often. It says in listing that granularity is >> 4 bytes, I assume that it has a sample for each of 4-byte chunks of binary >> code, so that it must have such information. My kernel is compiled with: >> >> makeoptions DEBUG=-g >> >> so kgdb does know where are instructions for each line of source code. >> How can I obtain this info from profiling? It also would be useful to know >> which places do calls to that bcmp() and rn_match(). -- WBR, Vadim Goncharov. ICQ#166852181 mailto:vadim_nuclight@mail.ru [Moderator of RU.ANTI-ECOLOGY][FreeBSD][http://antigreen.org][LJ:/nuclight] From owner-freebsd-performance@FreeBSD.ORG Wed Dec 3 11:20:59 2008 Return-Path: Delivered-To: freebsd-performance@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0659A1065688 for ; Wed, 3 Dec 2008 11:20:59 +0000 (UTC) (envelope-from gofp-freebsd-performance@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.freebsd.org (Postfix) with ESMTP id DB9D38FC1A for ; Wed, 3 Dec 2008 11:20:57 +0000 (UTC) (envelope-from gofp-freebsd-performance@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1L7pmp-0000Y2-VU for freebsd-performance@freebsd.org; Wed, 03 Dec 2008 11:20:55 +0000 Received: from 195.208.174.178 ([195.208.174.178]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 03 Dec 2008 11:20:55 +0000 Received: from vadim_nuclight by 195.208.174.178 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 03 Dec 2008 11:20:55 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-performance@freebsd.org From: Vadim Goncharov Date: Wed, 3 Dec 2008 11:20:48 +0000 (UTC) Organization: Nuclear Lightning @ Tomsk, TPU AVTF Hostel Lines: 38 Message-ID: References: <3bbf2fe10811230502t3cc52809i6ac91082f780b730@mail.gmail.com> X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 195.208.174.178 X-Comment-To: Attilio Rao User-Agent: slrn/0.9.8.1 (FreeBSD) Sender: news Subject: Re: [PATCH] pmcannotate tool X-BeenThere: freebsd-performance@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: vadim_nuclight@mail.ru List-Id: Performance/tuning List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Dec 2008 11:20:59 -0000 Hi Attilio Rao! On Sun, 23 Nov 2008 14:02:22 +0100; Attilio Rao wrote about '[PATCH] pmcannotate tool': > pmcannotate is a tool that prints out sources of a tool (in C or > assembly) with inlined profiling informations retrieved by a prior > pmcstat analysis. > If compared with things like callgraph generation, it prints out > profiling on a per-instance basis and this can be useful to find, for > example, badly handled caches, too high latency instructions, etc. [...] > objdump is not the only one tool on which pmcannotare rely. Infact, in > order to have it working, pmcstat needs to be present too because we > need to retrieve, from the pmcstat raw output, informations about the > sampled PCs (in particular the name of the function they live within, > its start and ending addresses). As long as currently pmcstat doesn't > return those informations, a new option has been added to the tool > (-m) which can extract (from a raw pmcstat output) all pc sampled, > name of the functions and symbol bundaries they live within. [...] > The patch can be found here: > http://www.freebsd.org/~attilio/pmcannotate.diff/ > where pmcannotate/ dir contains the code and needs to go under > /usr/src/usr.sbin/ and the patch has diffs against pmcstat and > Makefile. It looks like this the thing I need, please see parallel thread "hwpmc granularity and 6.4 network performance", I have CPU hog ipfw_chk() which is 1200+ lines long and want to know which parts are most hogs. But that part of your patch which is for pmcstat isn't applying to 6.4 :( Could you please provide another for this ver? -- WBR, Vadim Goncharov. ICQ#166852181 mailto:vadim_nuclight@mail.ru [Moderator of RU.ANTI-ECOLOGY][FreeBSD][http://antigreen.org][LJ:/nuclight] From owner-freebsd-performance@FreeBSD.ORG Fri Dec 5 15:01:10 2008 Return-Path: Delivered-To: freebsd-performance@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 78EAD1065675 for ; Fri, 5 Dec 2008 15:01:10 +0000 (UTC) (envelope-from raykinsella78@gmail.com) Received: from mail-qy0-f18.google.com (mail-qy0-f18.google.com [209.85.221.18]) by mx1.freebsd.org (Postfix) with ESMTP id 1B7C38FC12 for ; Fri, 5 Dec 2008 15:01:09 +0000 (UTC) (envelope-from raykinsella78@gmail.com) Received: by qyk11 with SMTP id 11so42161qyk.19 for ; Fri, 05 Dec 2008 07:01:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:mime-version:content-type; bh=4HizaYceovFblLjsUDXRv7wINU1s3cFBaQWAkEKxP/U=; b=LN1HI6K4V1op8e82KUaPLGtbw/Z9moaDaBv9HtceZYthaxhjNt9cDFF/bfgFHfmBqx g2UVe4FMu8PK0eCsQshjR1K+4IOoJ/4v4EKHlIgcKZxEHYB6XwRwFvAECQPwchADTvum +dAgqW/8RNjn/kRcSd/ZfL7LLpgGVXdl1GiFI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type; b=k/Q0GTEeDeaFAVacXOqU9n7/d6zlWlha6fxjb6XYmCTtfNtm2tfnxmslBwcoyQrlX4 2SB2CZiCDN71UmB8PUMslul3zk4HwPtx8sPBLtDrepeihY77Jlj8IQAdB9Lwfu5HPA3V IVCMaJgkF0q7GTzty9sMxXAH40TGEv1j8E34I= Received: by 10.214.60.1 with SMTP id i1mr129201qaa.286.1228489269076; Fri, 05 Dec 2008 07:01:09 -0800 (PST) Received: by 10.214.243.19 with HTTP; Fri, 5 Dec 2008 07:01:09 -0800 (PST) Message-ID: <584ec6bb0812050701t4bcccb1fr214370f4535ae1d0@mail.gmail.com> Date: Fri, 5 Dec 2008 15:01:09 +0000 From: "Ray Kinsella" To: freebsd-performance@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Thread priority in FreeBSD X-BeenThere: freebsd-performance@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Performance/tuning List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Dec 2008 15:01:10 -0000 Hi all, I have a problem trying to influence thread scheduling in FreeBSD. There are three threads I am interested the priority of:- a. Enqueue Thread: - Enqueues data in a circular buffer b. Interrupt Handler: - Signals that data in the circular buffer has been processed and in ready for removal - Queues an entry on a task queue so the data is removed from the circular buffer asynchronousily - Data is processed by a pci card c. Task Queue Thread: - Dequeues request from a task queue. - Dequeues data from the circular buffer. *Objective: *I want to prioritise the *Enqueue Thread, *such that it will always executes until the circular buffer is exhausted of space. I want the *Task Queue Thread* to have the lowest priority such that it only runs when the *Enqueue Thread* has no work to do. *Observed behaviour: *I set the *Enqueue Thread, *to have a priority of PRI_MAX_KERN (0) I set the *Task Queue Thread,* to have a priority of PRI_MIN_KERN (64) In the main I see the following scheduling:- ... *Enqueue Thread, *Enqueues serveral requests on the circular buffer *Interrupt Handler*, Interrupts the *Enqueue Thread, *puts requests on a taskqueue for async processing. *Task Queue Thread, *Dequeues the request from a taskqueue and the data from the circular buffer *Enqueue Thread, *Enqueues serveral requests on the circular buffer *Interrupt Handler*, Interrupts the *Enqueue Thread**, *puts requests on a taskqueue for async processing. *Task Queue Thread, *Dequeues the request from a taskqueue and the data from the circular buffer .. No matter what I do with thread priorities, the *Task Queue Thread *always follows the *Interrupt Handler. * *Ideal behaviour* Ideally I would get the following behaviour, were *Enqueue Thread *will always run instead of *Task Queue Thread *thread while it has work to do. *Enqueue Thread, *Enqueues serveral requests on the circular buffer *Interrupt Handler*, Interrupts the *Enqueue Thread, *puts requests on a taskqueue for async processing. *Enqueue Thread, *Enqueues serveral requests on the circular buffer *Interrupt Handler*, Interrupts the *Enqueue Thread**, *puts requests on a taskqueue for async processing. *Enqueue Thread, *Enqueues serveral requests on the circular buffer *Interrupt Handler*, Interrupts the *Enqueue Thread**, *puts requests on a taskqueue for async processing. *Enqueue Thread, *yields timeslices as the circular buffer is maxed out *Task Queue Thread, *Dequeues the request from a taskqueue and the data from the circular buffer *Task Queue Thread, *Dequeues the request from a taskqueue and the data from the circular buffer *Task Queue Thread, *Dequeues the request from a taskqueue and the data from the circular buffer Any idea's how to encourage the scheduler to adopt this behaviour ? Thanks Ray Kinsella * * From owner-freebsd-performance@FreeBSD.ORG Fri Dec 5 15:02:26 2008 Return-Path: Delivered-To: freebsd-performance@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B68AB106564A for ; Fri, 5 Dec 2008 15:02:26 +0000 (UTC) (envelope-from raykinsella78@gmail.com) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.24]) by mx1.freebsd.org (Postfix) with ESMTP id 696D58FC0C for ; Fri, 5 Dec 2008 15:02:26 +0000 (UTC) (envelope-from raykinsella78@gmail.com) Received: by qw-out-2122.google.com with SMTP id 9so9511qwb.7 for ; Fri, 05 Dec 2008 07:02:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:in-reply-to:mime-version:content-type:references; bh=faHwGvv8uEV9DVnn4wRuezdbwEWUCntTBtJj/tNB4Ks=; b=xIPP9Mz+xLnLfjHBFZKzTuPGCyetZn5jPdTcJzY21dYms2bln8lNUSnsB5/0GxzpgY T4hNbW0kwJxMuAYxb5uVxJZ9vuhJwbKMebtapnT38Mc1MTIIQN1wUqVzWwfv5f2E3JKC j9FMo4Nu7j+OJo4aqi5h0syfDcc9GGMTHr2sc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:in-reply-to:mime-version :content-type:references; b=NHorBfrprovFbmaw/acoR9SiTAWFAfwX9GtataHcdMPFll16LrEdbstPSi9ry93Ia7 Rmhz//TtZZvPvwkmDlj/uyjrXzZuUf5FGuQOt7JnIXRx9FpNdZBON5hO+UzPu3tsx9qk o2sK9V1jQM5v8bbF5uoM4sCfdGdDjJbRUiQ1g= Received: by 10.214.148.10 with SMTP id v10mr131404qad.287.1228489345585; Fri, 05 Dec 2008 07:02:25 -0800 (PST) Received: by 10.214.243.19 with HTTP; Fri, 5 Dec 2008 07:02:25 -0800 (PST) Message-ID: <584ec6bb0812050702j7dbf5b54k87d2cb4e4f6fa8b4@mail.gmail.com> Date: Fri, 5 Dec 2008 15:02:25 +0000 From: "Ray Kinsella" To: freebsd-performance@freebsd.org In-Reply-To: <584ec6bb0812050701t4bcccb1fr214370f4535ae1d0@mail.gmail.com> MIME-Version: 1.0 References: <584ec6bb0812050701t4bcccb1fr214370f4535ae1d0@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Re: Thread priority in FreeBSD X-BeenThere: freebsd-performance@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Performance/tuning List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Dec 2008 15:02:26 -0000 Apologies, I neglected to clarify, I am of course talking about Kernel Threads. On Fri, Dec 5, 2008 at 3:01 PM, Ray Kinsella wrote: > Hi all, > > I have a problem trying to influence thread scheduling in FreeBSD. > There are three threads I am interested the priority of:- > > a. Enqueue Thread: > - Enqueues data in a circular buffer > > b. Interrupt Handler: > - Signals that data in the circular buffer has been processed and in ready > for removal > - Queues an entry on a task queue so the data is removed from the circular > buffer asynchronousily > - Data is processed by a pci card > > c. Task Queue Thread: > - Dequeues request from a task queue. > - Dequeues data from the circular buffer. > > *Objective: > > *I want to prioritise the *Enqueue Thread, *such that it will always > executes until the circular buffer is exhausted of space. > I want the *Task Queue Thread* to have the lowest priority such that it > only runs when the *Enqueue Thread* has no work to do. > > *Observed behaviour: > > *I set the *Enqueue Thread, *to have a priority of PRI_MAX_KERN (0) > I set the *Task Queue Thread,* to have a priority of PRI_MIN_KERN (64) > > In the main I see the following scheduling:- > > ... > *Enqueue Thread, *Enqueues serveral requests on the circular buffer > *Interrupt Handler*, Interrupts the *Enqueue Thread, *puts requests on a > taskqueue for async processing. > *Task Queue Thread, *Dequeues the request from a taskqueue and the data > from the circular buffer > *Enqueue Thread, *Enqueues serveral requests on the circular buffer > *Interrupt Handler*, Interrupts the *Enqueue Thread**, *puts requests on a > taskqueue for async processing. > *Task Queue Thread, *Dequeues the request from a taskqueue and the data > from the circular buffer > .. > > No matter what I do with thread priorities, the *Task Queue Thread *always > follows the *Interrupt Handler. > * > *Ideal behaviour* > > Ideally I would get the following behaviour, were *Enqueue Thread *will > always run instead > of *Task Queue Thread *thread while it has work to do. > > *Enqueue Thread, *Enqueues serveral requests on the circular buffer > *Interrupt Handler*, Interrupts the *Enqueue Thread, *puts requests on a > taskqueue for async processing. > *Enqueue Thread, *Enqueues serveral requests on the circular buffer > *Interrupt Handler*, Interrupts the *Enqueue Thread**, *puts requests on a > taskqueue for async processing. > *Enqueue Thread, *Enqueues serveral requests on the circular buffer > *Interrupt Handler*, Interrupts the *Enqueue Thread**, *puts requests on a > taskqueue for async processing. > *Enqueue Thread, *yields timeslices as the circular buffer is maxed out > *Task Queue Thread, *Dequeues the request from a taskqueue and the data > from the circular buffer > *Task Queue Thread, *Dequeues the request from a taskqueue and the data > from the circular buffer > *Task Queue Thread, *Dequeues the request from a taskqueue and the data > from the circular buffer > > Any idea's how to encourage the scheduler to adopt this behaviour ? > > Thanks > > Ray Kinsella > > * > > > * >