Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1750900AbcCEUPS (ORCPT ); Sat, 5 Mar 2016 15:15:18 -0500 Received: from mail-wm0-f44.google.com ([74.125.82.44]:33465 "EHLO mail-wm0-f44.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750732AbcCEUPM (ORCPT ); Sat, 5 Mar 2016 15:15:12 -0500 MIME-Version: 1.0 In-Reply-To: References: Date: Sat, 5 Mar 2016 21:15:11 +0100 Message-ID: Subject: Re: SCSI sr driver: parallel writes to optical serialized which hurts performance (sr_mutex) From: Johan de Jong To: linux-kernel@vger.kernel.org Cc: Thomas Schmitt Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1432 Lines: 32 Dear developers, In the mean time I have applied and tested the 2013 patch by Otto Meta: http://marc.info/?l=linux-scsi&m=135705061804384&w=2 which, in short, replaces mutex_lock(&sr_mutex) (global mutex), that was introduced in 2010 to replace lock_kernel(), by per-device mutexes and allowing concurrent ioctl(SG_IO) in different processes with different sr devices. I had to patch some parts by hand as the posted patch did not slide seamlessly into my more current source tree, but I'm happy to report that the patch indeed does what it intends and solves the performance issue with accessing multiple sr devices concurrently. Repeated concurrent writes to three SATA burners have shown reliable and performance penalty free runs. In addition, repeated concurrent drive tray open and close (eject (-t) /dev/sr0 & eject (-t) /dev/sr1 & eject (-t) /dev/sr2) commands result in simultaneous (as opposed to the unpatched kernel) and reliable tray movement with no visible indications of locking problems caused by the patch either physically or in the kernel logs. I have been running the patched kernel for a number of days now to full satisfaction and relief. I would therefore venture to suggest that mutex_lock(&sr_mutex) is indeed the cause of the severe performance penalty and that the 2013 Otto Meta patch proposes a viable remedy that bears nomination for patching into the main kernel tree. Sincerely, Johan de Jong