From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrei Warkentin Subject: Re: MMC quirks relating to performance/lifetime. Date: Fri, 25 Feb 2011 05:02:18 -0600 Message-ID: References: <201102231709.05036.arnd@arndb.de> <201102241024.01437.arnd@arndb.de> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: linux-arm-kernel@lists.infradead.org, linux-fsdevel@vger.kernel.org, Linus Walleij , linux-mmc@vger.kernel.org To: Arnd Bergmann Return-path: Received: from exprod5og117.obsmtp.com ([64.18.0.149]:59827 "EHLO exprod5og117.obsmtp.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932389Ab1BYLCV convert rfc822-to-8bit (ORCPT ); Fri, 25 Feb 2011 06:02:21 -0500 In-Reply-To: <201102241024.01437.arnd@arndb.de> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On Thu, Feb 24, 2011 at 3:24 AM, Arnd Bergmann wrote: > Unlike the sysfs interface, the code does not need to be future-proof= , > it can always be changed if we feel the code becomes more maintainabl= e > by doing it another way. > > The approach that I'd like to see here is: > > * Start out with an ad-hoc patch for a quirk (like the one you alread= y > =A0have). > * Add a boolean variable to enable it per card. > * Get performance data for this quirk to show that it's useful in > =A0real-world workloads for some cards but counterproductive for othe= rs > * Get the patch into the mmc tree. > * Repeat for the next quirk > * When the code becomes overly complicated after adding all the quirk= s, > =A0decide on a good strategy to move the code around, and do a new pa= tch. > Yup. I understand :-). That's the strategy I'm going to follow. For page_size-alignment/splitting I'm looking at the block layer now. Is that the right approach or should I still submit a (cleaned up) patch to mmc/card/block.c for that performance improvement? The other (Toshiba quirk) is obviously a quirk belonging to mmc/card/block.c. > I understand that you are convinced that you will need the indirect f= unction > calls in the end. That is fine, just don't add them before they are > actually needed -- that would only make it harder for you to get the = first > patch included. > > Note that the situation is very different for user interfaces such as= sysfs: > You need to plan ahead because once the interface is merged upstream,= it > can never be changed. When you submit a patch that introduces a new s= ysfs > interface, it has to be documented, and you have to convince the revi= ewers > that it is sufficient to cover all the cases it is designed for, whil= e > at the same time it is the most simple way to achieve this. Ok, thanks a lot for the explanation, I hadn't thought of it that way (and should have). A -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel= " in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html From mboxrd@z Thu Jan 1 00:00:00 1970 From: andreiw@motorola.com (Andrei Warkentin) Date: Fri, 25 Feb 2011 05:02:18 -0600 Subject: MMC quirks relating to performance/lifetime. In-Reply-To: <201102241024.01437.arnd@arndb.de> References: <201102231709.05036.arnd@arndb.de> <201102241024.01437.arnd@arndb.de> Message-ID: To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On Thu, Feb 24, 2011 at 3:24 AM, Arnd Bergmann wrote: > Unlike the sysfs interface, the code does not need to be future-proof, > it can always be changed if we feel the code becomes more maintainable > by doing it another way. > > The approach that I'd like to see here is: > > * Start out with an ad-hoc patch for a quirk (like the one you already > ?have). > * Add a boolean variable to enable it per card. > * Get performance data for this quirk to show that it's useful in > ?real-world workloads for some cards but counterproductive for others > * Get the patch into the mmc tree. > * Repeat for the next quirk > * When the code becomes overly complicated after adding all the quirks, > ?decide on a good strategy to move the code around, and do a new patch. > Yup. I understand :-). That's the strategy I'm going to follow. For page_size-alignment/splitting I'm looking at the block layer now. Is that the right approach or should I still submit a (cleaned up) patch to mmc/card/block.c for that performance improvement? The other (Toshiba quirk) is obviously a quirk belonging to mmc/card/block.c. > I understand that you are convinced that you will need the indirect function > calls in the end. That is fine, just don't add them before they are > actually needed -- that would only make it harder for you to get the first > patch included. > > Note that the situation is very different for user interfaces such as sysfs: > You need to plan ahead because once the interface is merged upstream, it > can never be changed. When you submit a patch that introduces a new sysfs > interface, it has to be documented, and you have to convince the reviewers > that it is sufficient to cover all the cases it is designed for, while > at the same time it is the most simple way to achieve this. Ok, thanks a lot for the explanation, I hadn't thought of it that way (and should have). A