From: Tim Small <tim@buttersideup.com>
To: Christoph Hellwig <hch@infradead.org>, Wakko Warner <wakko@animx.eu.org>
Cc: linux-scsi@vger.kernel.org
Subject: Re: Very slow throughput when using cdparanoia on two SATA CDROM drives with /dev/sr but not /dev/sg
Date: Thu, 20 Nov 2014 08:16:06 +0000 [thread overview]
Message-ID: <546DA346.7050507@buttersideup.com> (raw)
In-Reply-To: <20141120063420.GA18238@infradead.org>
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_info (as per Arnd Bergmann/ James Bottomley's
discussion here https://lkml.org/lkml/2012/2/28/305 ).
This seems to work in a quick test testing (simultaneous cdparanoia on
8-or-so drives took ~10 minutes, whereas last time I tried that it took
more than 18 hours), but I've been short on time to do much more.
At first inspection, it looks like it's just the cdrom-specific ioctls
in drivers/cdrom/cdrom.c which aren't safely preemptible (my conclusion
based on the fact that scsi_ioctl etc. is called elsewhere without
locking (e.g. from /dev/sg and /dev/sd devices - I haven't looked at ).
As a result, I was wondering about moving the mutex_lock / unlock, so
that they wrap just the cdrom-specific ioctl calls instead, although I
suspect there won't be a huge performance benefit from doing so, it
would have the advantage that all the code related to the new mutex to
be moved into cdrom.c
Hopefully I'll grab a bit of time to work on this later this week, and
post a patch.
Cheers,
Tim.
next prev parent reply other threads:[~2014-11-20 8:16 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-11-06 13:25 Very slow throughput when using cdparanoia on two SATA CDROM drives with /dev/sr but not /dev/sg Tim Small
2014-11-07 21:37 ` Wakko Warner
2014-11-20 6:34 ` Christoph Hellwig
2014-11-20 8:16 ` Tim Small [this message]
2014-11-21 10:02 ` Christoph Hellwig
2014-11-25 14:09 ` [PATCH 0/4] Fix performance burning or extracting audio etc. from multiple optical drives Tim Small
2014-11-25 16:26 ` Christoph Hellwig
2014-11-25 16:30 ` Jens Axboe
2014-11-25 16:32 ` Christoph Hellwig
2014-11-25 16:36 ` Jens Axboe
2014-11-26 15:33 ` Tim Small
2014-11-26 20:34 ` Tim Small
2014-11-26 23:01 ` Julian Calaby
2014-11-27 7:08 ` Tim Small
2015-11-05 1:38 ` Wakko Warner
2015-11-05 9:36 ` Tim Small
2014-11-25 14:09 ` [PATCH 1/4] enable cdrom_ioctl() to be called without holding ex-BKL mutexes Tim Small
2014-11-25 14:09 ` [PATCH 2/4] Remove ex-BKL lock from ioctl path; fix simultaneous record on >1 drive Tim Small
2014-11-25 14:09 ` [PATCH 3/4] " Tim Small
2014-11-25 14:09 ` [PATCH 4/4] " Tim Small
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=546DA346.7050507@buttersideup.com \
--to=tim@buttersideup.com \
--cc=hch@infradead.org \
--cc=linux-scsi@vger.kernel.org \
--cc=wakko@animx.eu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.