Date: Sun, 09 Aug 2009 11:56:06 -0600 (MDT) From: "M. Warner Losh" <imp@bsdimp.com> To: attilio@freebsd.org Cc: freebsd-usb@freebsd.org Subject: Re: Performance issues Message-ID: <20090809.115606.1943337744.imp@bsdimp.com> In-Reply-To: <3bbf2fe10908091038m3efb3612l2923d8b3238e111f@mail.gmail.com> References: <20090809.105507.-646227496.imp@bsdimp.com> <3bbf2fe10908091025t7f8d00dbw5b0589728cf400ad@mail.gmail.com> <3bbf2fe10908091038m3efb3612l2923d8b3238e111f@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
In message: <3bbf2fe10908091038m3efb3612l2923d8b3238e111f@mail.gmail.com>
Attilio Rao <attilio@freebsd.org> writes:
: 2009/8/9 Attilio Rao <attilio@freebsd.org>:
: > 2009/8/9 M. Warner Losh <imp@bsdimp.com>:
: >> In message: <200908091840.55000.hselasky@c2i.net>
: >> Hans Petter Selasky <hselasky@c2i.net> writes:
: >> : On Sunday 09 August 2009 18:23:41 M. Warner Losh wrote:
: >> : > Any ideas how to track this down?
: >> :
: >> : Hi,
: >> :
: >> : USB is only draining from "usbd_transfer_drain()" in
: >> : /sys/dev/usb/usb_transfer.c . You could add a print including the backtrace
: >> : and see if that function gets called when it freezes.
: >>
: >> Ummm. No. Adding a traceback print to a function that's called 60
: >> times a second in steady state doesn't seem like a viable option.
: >>
: >> : Else I would try to compile a fresh kernel from USB P4. There are
: >> : some patches there in relation to the recent newbus lock change,
: >> : that might help.
: >>
: >> This kernel predates the newbus lock change.
: >>
: >> : USB uses uppercase "WDRAIN". Is your printout lowercase "wdrain" ?
: >>
: >> Yes.
: >
: > That's used by the buffer cache in order to reduce pressure of
: > asynchronous writes. It waits for other writes to complete before to
: > go on. Probabilly, I/O requests get stuck for another reasong starving
: > the asynchronous requests queue flushing.
:
: It would be also interesting to understand if the allowed requests are
: just lost or still pending and can be effectively flushed out. Can you
: please show the content of vm.runningbufspace ?
The writes eventually happen, it is just stalled. I'll run the
experiment again and see if I can give you that info...
: However, keep in mind that as long as the buffer cache is global, if
: the bluethoot dongle breaks I/O requests, it can be the offending
: part, so USB may not be involved.
I'm not sure I understand this statement. I think what is happening
is a race between multiple devices. I also see problems when I have
both a usb disk and a usb dvd burner attached. I didn't used to see
that problem (I made hundreds of DVDs of my son's hockey games). Now,
I can't even burn one disc to save my life...
Besides, the bluetooth dongle isn't going to be doing any disk block
requests, so how can that interfere with the buffer cache?
Warner
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20090809.115606.1943337744.imp>