Many people, including myself, have observed system stalls when using
usb-storage. It happens when copying large amounts of data to a USB device
-- everything (except the USB access) just stops for a little while. My
best guess is that the block cache is filling up (easy since USB is so
slow).
The question is, what is the best way to handle this. I'm guessing that
increasing the priority of the usb-storage control thread will help, but
that's just a guess. I'm not even sure how to go about doing that, tho...
This is seen on 2.4 and 2.5/6 kernels.
Anyone have any ideas?
Matt
--
Matthew Dharm Home: [email protected]
Maintainer, Linux USB Mass Storage Driver
M: No, Windows doesn't have any nag screens.
C: Then what are those blue and white screens I get every day?
-- Mike and Cobb
User Friendly, 1/4/1999
Am Donnerstag, 24. Juli 2003 05:00 schrieb Matthew Dharm:
> Many people, including myself, have observed system stalls when using
> usb-storage. It happens when copying large amounts of data to a USB device
> -- everything (except the USB access) just stops for a little while. My
> best guess is that the block cache is filling up (easy since USB is so
> slow).
Can you do a vmstat run? That should provide conclusive data.
If so, write throteling is failing.
> The question is, what is the best way to handle this. I'm guessing that
> increasing the priority of the usb-storage control thread will help, but
> that's just a guess. I'm not even sure how to go about doing that, tho...
A kernel thread in the block io path has to have a higher priority than
any user task. Otherwise a priority inversion is possible.
Regards
Oliver
On Sun, Jul 27, 2003 at 08:24:44AM +0200, Oliver Neukum wrote:
> Am Donnerstag, 24. Juli 2003 05:00 schrieb Matthew Dharm:
> > Many people, including myself, have observed system stalls when using
> > usb-storage. It happens when copying large amounts of data to a USB device
> > -- everything (except the USB access) just stops for a little while. My
> > best guess is that the block cache is filling up (easy since USB is so
> > slow).
>
> Can you do a vmstat run? That should provide conclusive data.
> If so, write throteling is failing.
I'll set up some tests and get back to you...
> > The question is, what is the best way to handle this. I'm guessing that
> > increasing the priority of the usb-storage control thread will help, but
> > that's just a guess. I'm not even sure how to go about doing that, tho...
>
> A kernel thread in the block io path has to have a higher priority than
> any user task. Otherwise a priority inversion is possible.
Reasonable. So, other than renice at the command line, how does one go
about setting this?
Matt
--
Matthew Dharm Home: [email protected]
Maintainer, Linux USB Mass Storage Driver
Somebody call an exorcist!
-- Dust Puppy
User Friendly, 5/16/1998
Matthew Dharm <[email protected]> writes:
> On Sun, Jul 27, 2003 at 08:24:44AM +0200, Oliver Neukum wrote:
> > Am Donnerstag, 24. Juli 2003 05:00 schrieb Matthew Dharm:
> > > The question is, what is the best way to handle this. I'm guessing that
> > > increasing the priority of the usb-storage control thread will help, but
> > > that's just a guess. I'm not even sure how to go about doing that, tho...
> >
> > A kernel thread in the block io path has to have a higher priority than
> > any user task. Otherwise a priority inversion is possible.
>
> Reasonable. So, other than renice at the command line, how does one go
> about setting this?
Try this patch. The loop device thread is doing the same thing.
diff -puN drivers/usb/storage/usb.c~usb-priority drivers/usb/storage/usb.c
--- linux/drivers/usb/storage/usb.c~usb-priority Sun Jul 27 10:56:02 2003
+++ linux-petero/drivers/usb/storage/usb.c Sun Jul 27 10:56:47 2003
@@ -302,6 +302,8 @@ static int usb_stor_control_thread(void
current->flags |= PF_IOTHREAD;
+ set_user_nice(current, -20);
+
unlock_kernel();
/* signal that we've started the thread */
--
Peter Osterlund - [email protected]
http://w1.894.telia.com/~u89404340