Re: [PATCH 0/4] Fix performance burning or extracting audio etc. from multiple optical drives.
On 05/11/15 01:38, Wakko Warner wrote: > I tested on a system with 3 drives. ejecting all drives didn't happen at > the same time, but I think it's because they are different brands and one > didn't have a disc in. I did notice the leds coming on about the same time > though. eject -t on all drives happened at the same time. > > The patch I used previously on 3.3.0 removed all mutex_lock and mutex_unlock > lines from sr.c where as this patchset didn't. I plan on trying to burn 3 > dvds to see if it works. > > Thanks for your work on the patches. No problem. I haven't had any time to follow up (and probably won't for the foreseeable - I've got far too much on at the moment unfortunately), and the locking issues looked non-trivial unfortunately. In my testing burning, and audio extracting etc. worked pretty flawlessly IIRC, it was just the eject/load path which seemed to have locking issues. The test was just a shell scripts which ran: while true ; do eject /dev/sr0 ; eject -T /dev/sr0 ; done for every drive in the system simultaneously. Hopefully it's a good start if someone wants to pick it up. It's possible that there's an easy way of leaving the old mutexes (or adding more) around the relevant open/eject/load paths only, but I can't remember the code now unfortunately. If anyone wants to have a go, I think I can probably rig up about 8 drives to a testrig here, and will be happy to give it a test. Tim. -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/4] Fix performance burning or extracting audio etc. from multiple optical drives.
Tim Small wrote: > Fix performance burning or extracting audio etc. from multiple optical > drives. I know this is a bit late and is still not in 4.3. I applied 2 of the patches. I did not apply the ide-cd, the paride nor the gdrom since I don't have any of those. > Patches are against 3.18.0-rc6+ I had to make some modifications to the patch for sr.c since it has changed since. cdrom.[ch] worked verbatim. I tested on a system with 3 drives. ejecting all drives didn't happen at the same time, but I think it's because they are different brands and one didn't have a disc in. I did notice the leds coming on about the same time though. eject -t on all drives happened at the same time. The patch I used previously on 3.3.0 removed all mutex_lock and mutex_unlock lines from sr.c where as this patchset didn't. I plan on trying to burn 3 dvds to see if it works. Thanks for your work on the patches. -- Microsoft has beaten Volkswagen's world record. Volkswagen only created 22 million bugs. -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/4] Fix performance burning or extracting audio etc. from multiple optical drives.
On 26/11/14 15:33, Tim Small wrote: I decided to exercise the eject code path a bit more by triggering simultaneous eject commands on all 11 optical drives in my test box, followed by simultaneous close-tray commands, repeatedly. ... Unfortunately running these tests did eventually make all further attempts to open /dev/sr* block on my test box. I've stared at the code for a while, but not making any headway currently, except that a blocking blk_execute_rq (called by test_unit_ready) is then causing all over cdrom open/close calls to block (because sr_mutex is held by sr_block_open(), and in turn calls check_disk_change... scsi_test_unit_ready). How do I work out why blk_execute_rq is blocking? # ps -l 3779 2383 3780 F S UID PID PPID C PRI NI ADDR SZ WCHAN TTYTIME CMD 1 D 0 2383 2 0 80 0 - 0 blk_ex ? 0:00 [kworker/1:2] 0 D 0 3779 1034 0 80 0 - 1057 blk_ex pts/0 0:00 eject -t /dev/sr7 0 D 0 3780 1034 0 80 0 - 0 sr_blo pts/0 0:00 [eject] /proc/3779/stack-[812e47cb] blk_execute_rq+0x16b/0x210 /proc/3779/stack-[a0291cb1] scsi_execute+0x141/0x1f0 [scsi_mod] /proc/3779/stack-[a0293e1e] scsi_execute_req_flags+0x8e/0x100 [scsi_mod] /proc/2383/stack-[812e47cb] blk_execute_rq+0x16b/0x210 /proc/2383/stack-[a0291cb1] scsi_execute+0x141/0x1f0 [scsi_mod] /proc/2383/stack-[a0293e1e] scsi_execute_req_flags+0x8e/0x100 [scsi_mod] /proc/2383/stack-[a02944f3] scsi_test_unit_ready+0x83/0x130 [scsi_mod] An extra data point, the drive is showing busy: # cat /sys/block/sr7/device/device_busy 1 I was wondering if this might be an unrelated bug in the drive or host adaptor driver? This device is attached to an old PCI card using pata_pdc2027x, and has an old firmware version, so I'm going to try and change both of those things and try again. Tim. -- To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/4] Fix performance burning or extracting audio etc. from multiple optical drives.
Hi Tim, On Thu, Nov 27, 2014 at 2:33 AM, Tim Small t...@seoss.co.uk wrote: On 25/11/14 16:30, Jens Axboe wrote: do we really need to do paride here? I did consider this, but I made the change there too on the basis that: . paride has received a few commits this year (and is listed as being maintained) . The change is trivial . It fixes a performance regression which was introduced during the BKL removal (mutex being retained by sleeping processes). I'm happy to drop it, if you prefer. Patches 2-4 have identical subjects, and no commit message... Sorry about that, will fix it with next version. Having just seen this thread from 2013: http://permalink.gmane.org/gmane.linux.scsi/79483 I decided to exercise the eject code path a bit more by triggering simultaneous eject commands on all 11 optical drives in my test box, followed by simultaneous close-tray commands, repeatedly. I haven't been able to reproduce the error reported in that email, but from observing the behaviour of the drives it looks like access to pata drives is being serialising elsewhere, so the issue in that link may have been fixed? Unfortunately running these tests did eventually make all further attempts to open /dev/sr* block on my test box. I've stared at the code for a while, but not making any headway currently, except that a blocking blk_execute_rq (called by test_unit_ready) is then causing all over cdrom open/close calls to block (because sr_mutex is held by sr_block_open(), and in turn calls check_disk_change... scsi_test_unit_ready). How do I work out why blk_execute_rq is blocking? As you're playing with locks, I assume you're running with LOCKDEP enabled? If not, that might tell you what's going on. Thanks, -- Julian Calaby Email: julian.cal...@gmail.com Profile: http://www.google.com/profiles/julian.calaby/ -- To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/4] Fix performance burning or extracting audio etc. from multiple optical drives.
On 26/11/14 23:01, Julian Calaby wrote: As you're playing with locks, I assume you're running with LOCKDEP enabled? If not, that might tell you what's going on. Hi, Sorry - I should have said - LOCKDEP is on, and not reporting anything... Cheers, Tim. -- To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/4] Fix performance burning or extracting audio etc. from multiple optical drives.
This looks reasonable to me. Jens, do you want to takes this through the block tree? Acked-by: Christoph Hellwig h...@lst.de -- To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/4] Fix performance burning or extracting audio etc. from multiple optical drives.
On 11/25/2014 09:26 AM, Christoph Hellwig wrote: This looks reasonable to me. Jens, do you want to takes this through the block tree? Acked-by: Christoph Hellwig h...@lst.de Yeah I can do that, though do we really need to do paride here? Tim, you also need to work on your changelogs. Please resend (dropping paride), and add proper subject and commit message. Patches 2-4 have identical subjects, and no commit message... -- Jens Axboe -- To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/4] Fix performance burning or extracting audio etc. from multiple optical drives.
On Tue, Nov 25, 2014 at 09:30:19AM -0700, Jens Axboe wrote: On 11/25/2014 09:26 AM, Christoph Hellwig wrote: This looks reasonable to me. Jens, do you want to takes this through the block tree? Acked-by: Christoph Hellwig h...@lst.de Yeah I can do that, though do we really need to do paride here? Well, no need to keep the mutex around in paride for no reason. But my preference would be to just kill off paride anyway :) -- To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/4] Fix performance burning or extracting audio etc. from multiple optical drives.
On 11/25/2014 09:32 AM, Christoph Hellwig wrote: On Tue, Nov 25, 2014 at 09:30:19AM -0700, Jens Axboe wrote: On 11/25/2014 09:26 AM, Christoph Hellwig wrote: This looks reasonable to me. Jens, do you want to takes this through the block tree? Acked-by: Christoph Hellwig h...@lst.de Yeah I can do that, though do we really need to do paride here? Well, no need to keep the mutex around in paride for no reason. But my preference would be to just kill off paride anyway :) That's sort of my point. Performance optimization and paride, well... But it's not a huge deal, we can apply it. -- Jens Axboe -- To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
