System stalls using usb-storage
Subsystems (2)
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
Signature · 7 lines
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:
Quoted 5 lines
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.
Quoted 3 lines
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
Quoted 9 lines · Oliver Neukum
Am Donnerstag, 24. Juli 2003 05:00 schrieb Matthew Dharm:
Quoted 5 lines
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...
Quoted 6 lines
Quoted 3 lines
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
Signature · 6 lines
Matthew Dharm Home: [email protected] Maintainer, Linux USB Mass Storage Driver Somebody call an exorcist! -- Dust Puppy User Friendly, 5/16/1998
Quoted 11 lines · Matthew Dharm
Quoted 7 lines · Oliver Neukum
Am Donnerstag, 24. Juli 2003 05:00 schrieb Matthew Dharm:
Quoted 3 lines
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.
drivers/usb/storage/usb.c renamed from drivers/usb/storage/usb.c~usb-priority +2 -0
@@ -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 */
Signature · 2 lines
Peter Osterlund - [email protected] http://w1.894.telia.com/~u89404340