Date: Thu, 28 Sep 2006 05:14:02 +1000 From: Peter Jeremy <peterjeremy@optushome.com.au> To: Scott Long <scottl@samsco.org> Cc: freebsd-stable@freebsd.org, Oliver Brandmueller <ob@e-Gitt.NET>, John Baldwin <jhb@freebsd.org> Subject: Re: 6.2 SHOWSTOPPER - em completely unusable on 6.2 Message-ID: <20060927191402.GB932@turion.vk2pj.dyndns.org> In-Reply-To: <451AA7B1.5080202@samsco.org> References: <451A1375.5080202@gneto.com> <20060927071538.GF22229@e-Gitt.NET> <451A4189.5020906@samsco.org> <20060927152824.GJ22229@e-Gitt.NET> <20060927155553.GB14563@icarus.home.lan> <20060927155904.GM22229@e-Gitt.NET> <451AA7B1.5080202@samsco.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--QKdGvSO+nmPlgiQ/ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, 2006-Sep-27 10:32:49 -0600, Scott Long wrote: >My theory here is that something in the kernel, likely VM/VFS, is >holding the Giant lock for an inordinate amount of time. In the past (RELENG_5) I've had major problems with syncer delaying interrupt threads for long periods (I've seen 8msec). See http://lists.freebsd.org/pipermail/freebsd-stable/2005-February/012346.html I'm not sure if this is still a problem (but I am still having some problems which may be caused by excessive interrupt and will be doing some debugging as I get time). >I have a few ideas on tracking down the root cause, but they are pretty >pretty painful and slow. In my case, I was fairly certain that the problem I was seeing was excessive interrupt latency for my driver. The approach I took was to capture TSC, IRQ number and curproc address in lapic_handle_intr(), atpic_handle_intr() and at the beginning of my interrupt handler into a ring buffer. I'd dump the ring buffer into a file using a userland tool and then post-process the file looking for oddities. In my case, there was a _very_ high correlation between long latencies and syncer. If anyone's interested in this approach, I can provide the relevant code diffs. >2. Add INTR_FAST shims to the usb and ichsmb drivers so that neither >uses an ithread. The problem I ran into with this approach was that my interrupt handler needs to use psignal(9) - which requires PROC_LOCK() which (AFAIK) isn't allowed in an INTR_FAST handler. It would be useful if our interrupt subsystem allowed both INTR_FAST and normal interrupt handlers to be defined. If an INTR_FAST handler is defined then it gets executed and defines whether its associated interrupt thread handler needs to be triggered. If there's no INTR_FAST handler then the interrupt thread is always triggered. --=20 Peter Jeremy --QKdGvSO+nmPlgiQ/ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQFFGs16/opHv/APuIcRAlchAJ9qHKfhfGbB7K0iy48PREH0mUXcDgCgkjur d1bJKRbBDGI0ZTkYDcUyz0k= =6bF7 -----END PGP SIGNATURE----- --QKdGvSO+nmPlgiQ/--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060927191402.GB932>