Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753913AbZCIKn2 (ORCPT ); Mon, 9 Mar 2009 06:43:28 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1753232AbZCIKnS (ORCPT ); Mon, 9 Mar 2009 06:43:18 -0400 Received: from vervifontaine.sonytel.be ([80.88.33.193]:63657 "EHLO vervifontaine.sonycom.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1753145AbZCIKnR (ORCPT ); Mon, 9 Mar 2009 06:43:17 -0400 Date: Mon, 9 Mar 2009 11:43:14 +0100 (CET) From: Geert Uytterhoeven To: Jens Axboe cc: Benjamin Herrenschmidt , Jim Paris , Vivien Chappelier , David Woodhouse , Arnd Bergmann , Geoff Levand , Linux/PPC Development , Cell Broadband Engine OSS Development , Linux Kernel Development , linux-mtd@lists.infradead.org Subject: Re: [PATCH/RFC] ps3/block: Add ps3vram-ng driver for accessing video RAM as block device In-Reply-To: <20090306190350.GD11787@kernel.dk> Message-ID: References: <20090305083701.GQ11787@kernel.dk> <20090305110940.GY11787@kernel.dk> <20090306074639.GN11787@kernel.dk> <20090306125832.GX11787@kernel.dk> <20090306190350.GD11787@kernel.dk> User-Agent: Alpine 2.00 (LRH 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-15 Content-Transfer-Encoding: 8BIT Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2560 Lines: 58 On Fri, 6 Mar 2009, Jens Axboe wrote: > On Fri, Mar 06 2009, Geert Uytterhoeven wrote: > > On Fri, 6 Mar 2009, Jens Axboe wrote: > > > On Fri, Mar 06 2009, Geert Uytterhoeven wrote: > > > > On Fri, 6 Mar 2009, Jens Axboe wrote: > > > > > On Thu, Mar 05 2009, Geert Uytterhoeven wrote: > > > > > > But then I noticed ps3vram_make_request() may be called concurrently, > > > > > > so I had to add a mutex to avoid data corruption. This slows the > > > > > > driver down, and in the end, the version with a thread turns out to be > > > > > > ca. 1% faster. The version without a thread is about 50 lines less > > > > > > code, though. > > > > > > > > > > That is correct, ->make_request_fn may get reentered. I'm not surprised > > > > > that performance dropped if you just shoved everything under a mutex. > > > > > You could be a little more smart and queue concurrent bio's for > > > > > processing when the current one is complete though, there are several > > > > > approaches there that be a lot faster than going all the way through the > > > > > IO stack and scheduler just to avoid concurrency. > > > > > > > > Yes, using a spinlock and queueing requests on a list if the driver is > > > > busy can be done after 2.6.29... > > > > > > Certainly. Even just replacing your current mutex with a spinlock during > > > the memcpy() would surely be a lot faster. Or even just grabbing the > > > mutex before calling into the write for the duration of the bio. The way > > > you do it is certain context switch death :-) > > > > It's not just the memcpy(). ps3vram_{up,down}load() call msleep(), so > > I cannot use a spinlock. > > Ah right, I hadn't looked close enough. But putting the mutex_lock() > outside of the bio_for_each_segment() is going to be much faster than > getting/releasing it for each segment. It doesn't seem to make any measurable difference, so I'm gonna leave it for now. With kind regards, Geert Uytterhoeven Software Architect Sony Techsoft Centre Europe The Corporate Village ? Da Vincilaan 7-D1 ? B-1935 Zaventem ? Belgium Phone: +32 (0)2 700 8453 Fax: +32 (0)2 700 8622 E-mail: Geert.Uytterhoeven@sonycom.com Internet: http://www.sony-europe.com/ A division of Sony Europe (Belgium) N.V. VAT BE 0413.825.160 ? RPR Brussels Fortis ? BIC GEBABEBB ? IBAN BE41293037680010 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/