Re: [PATCH 0/4] Fix performance burning or extracting audio etc. from multiple optical drives.

2015-11-05 Thread Tim Small
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 dri

Very slow throughput when using cdparanoia on two SATA CDROM drives with /dev/sr but not /dev/sg

2014-11-06 Thread Tim Small
Hello, I've got a big box of audio CDs to read, so I hooked up a load of SATA CDROM drives to a machine (Intel motherboard AHCI, and SATA SiI3124 controllers - in this example one was attached to each host controller), so that I could read them in parallel. I'm using kernel 3.16.3, with cdparanoi

Re: Very slow throughput when using cdparanoia on two SATA CDROM drives with /dev/sr but not /dev/sg

2014-11-20 Thread Tim Small
On 20/11/14 06:34, Christoph Hellwig wrote: > Wakko, any chance you could resend a patch to remove the mutex from the > ioctl path? I'm trying out some local changes which removes the ex-BKL mutex from sr_block_ioctl() in sr.c, and instead uses a per-drive mutex which I've added to cdrom_device_in

[PATCH 4/4] Remove ex-BKL lock from ioctl path; fix simultaneous record on >1 drive

2014-11-25 Thread Tim Small
Signed-off-by: Tim Small --- drivers/ide/ide-cd.c | 42 +++--- 1 file changed, 19 insertions(+), 23 deletions(-) diff --git a/drivers/ide/ide-cd.c b/drivers/ide/ide-cd.c index 0b510ba..946d458 100644 --- a/drivers/ide/ide-cd.c +++ b/drivers/ide/ide-cd.c

[PATCH 1/4] enable cdrom_ioctl() to be called without holding ex-BKL mutexes

2014-11-25 Thread Tim Small
Signed-off-by: Tim Small --- drivers/cdrom/cdrom.c | 86 +++ include/linux/cdrom.h | 1 + 2 files changed, 60 insertions(+), 27 deletions(-) diff --git a/drivers/cdrom/cdrom.c b/drivers/cdrom/cdrom.c index 5d28a45..c39bef1 100644 --- a/drivers

[PATCH 3/4] Remove ex-BKL lock from ioctl path; fix simultaneous record on >1 drive

2014-11-25 Thread Tim Small
Signed-off-by: Tim Small --- drivers/block/paride/pcd.c | 8 +--- drivers/cdrom/gdrom.c | 8 +--- 2 files changed, 2 insertions(+), 14 deletions(-) diff --git a/drivers/block/paride/pcd.c b/drivers/block/paride/pcd.c index 3b7c9f1..61cabfd 100644 --- a/drivers/block/paride/pcd.c

[PATCH 2/4] Remove ex-BKL lock from ioctl path; fix simultaneous record on >1 drive

2014-11-25 Thread Tim Small
Signed-off-by: Tim Small --- drivers/scsi/sr.c | 14 -- 1 file changed, 4 insertions(+), 10 deletions(-) diff --git a/drivers/scsi/sr.c b/drivers/scsi/sr.c index 2de44cc..93111b1 100644 --- a/drivers/scsi/sr.c +++ b/drivers/scsi/sr.c @@ -547,8 +547,6 @@ static int sr_block_ioctl

[PATCH 0/4] Fix performance burning or extracting audio etc. from multiple optical drives.

2014-11-25 Thread Tim Small
ment in the past, so hopefully this first attempt isn't too far of the mark... I've tested the IDE and SCSI subsystem patches, but I don't have any paride, or GDROM hardware (however the changes which are specific to these two are trivial). Cheers, Tim. Tim Small (4): enable

Re: [PATCH 0/4] Fix performance burning or extracting audio etc. from multiple optical drives.

2014-11-26 Thread Tim Small
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 wh

Re: [PATCH 0/4] Fix performance burning or extracting audio etc. from multiple optical drives.

2014-11-26 Thread Tim Small
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

Re: [PATCH 0/4] Fix performance burning or extracting audio etc. from multiple optical drives.

2014-11-26 Thread Tim Small
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