Re: USB performance bug since kernel 2.6.13 (CRITICAL???)

[Open Source <opensource3141@yahoo.com>]

Hi Alan (and all),

Thanks for your message.

There is an ioctl that is waiting for the URB to be reaped.
I am almost certain it is this syscall that is taking 4 ms (as
opposed to 1 ms with CONFIG_HZ=1000).

Let me ask a very specific question related to my
previous email about devio.c.

Say I have a process that has done the following:
--
        add_wait_queue(&ps->wait, &wait);
        for (;;) {
                __set_current_state(TASK_INTERRUPTIBLE);
                if ((as = async_getcompleted(ps)))
                        break;
                if (signal_pending(current))
                        break;
                usb_unlock_device(dev);
                schedule();
                usb_lock_device(dev);
        }
        remove_wait_queue(&ps->wait, &wait);
--

Then later, a USB interrupt triggers, and the following is called
after a bunch of code:
--
wake_up(&ps->wait)
--

Will the first piece of code wake up immediately or only after the
next HZ timeslice?  If it is the latter, which is what I am starting to
fear now, that would explain everything.  Then, the question is
whether or not there is anyway to improve this situation.  If it does
wake up immediatley, then the delay is elsewhere and probably
has nothing to do with kernel mode versus user mode issues.

Thanks again.


----- Original Message ----
From: Alan Cox <alan@lxorguk.ukuu.org.uk>
To: Open Source <opensource3141@yahoo.com>
Cc: Alan Stern <stern@rowland.harvard.edu>; linux-usb-devel@lists.sourceforge.net; WolfgangMües <wolfgang@iksw-muees.de>; linux-kernel@vger.kernel.org
Sent: Friday, October 13, 2006 4:41:44 PM
Subject: Re: [linux-usb-devel] USB performance bug since kernel 2.6.13 (CRITICAL???)

Ar Gwe, 2006-10-13 am 16:02 -0700, ysgrifennodd Open Source:
> clear understanding of what is causing it.  As it stands it doesn't
> seem like even the experts know exactly where this
> delay is being caused.

strace should tell you precisely how long each syscall takes if you ask
it to trace things nicely. If you have code trying to wait for a tiny
time then HZ will bump the wait to be longer (kernel or user) but for
other cases all should be fine either way.

The other issues like priority and paging caused delays can generally be
dealt with by having the relevant service code running mlockall and real
time priority.







-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/