From: Vitaly Wool <vwool@ru.mvista.com>
To: Alexander Belyakov <alexander.belyakov@intel.com>
Cc: "Korolev, Alexey" <alexey.korolev@intel.com>,
linux-mtd@lists.infradead.org, "Kutergin,
Timofey" <timofey.kutergin@intel.com>
Subject: Re: [PATCH/RFC] Linux MTD striping middle layer
Date: Tue, 21 Mar 2006 18:11:44 +0300 [thread overview]
Message-ID: <442017B0.4010508@ru.mvista.com> (raw)
In-Reply-To: <44201084.3000708@intel.com>
Alexander Belyakov wrote:
> Vitaly,
>
> 1. No. Striping itself does not kill XIP. But it's true that using XIP
> with striped volume will not give any performance increase.
I'm quite unsure that XIP will be working on any other platform that
yours if your changes are applied, sorry.
> 2. Please note, that mtdstripe.c is a just another middle layer module
> as mtdconcat.c or mtdpart.c, for example. It can be used on top of ANY
> command set.
So why didn't you provide a comprehensive patch for all the command sets?
>
> As it was described in original message, we have to provide correct
> thread switching process - it is NOT striping problem but more generic
> one. We have fixed it in cfi_cmdset_0001.c. And it can be fixed (CPT)
> or workarounded (Priority switching and udelay modification) for other
> command sets. CPT (Common polling thread) has also been made as
> turnable module so anyone in any command set implementation could use it.
What PREEMPT_ modes did you test it with?
>
> Another important thing to be mentioned. The patch below was validated
> on 4 different Intel flash chips (including Sibley) on arm-based
> platform. It works and gives up to 85% performance increase on two
> independent chips in system.
...on Intel ARM-like platform, I need to add. No other ARM platforms, I
guess :P
We had a somewhat heated discussion on your changes in IRC :)
My POV is -- the idea itself definitely has some added value but I'm not
sure if incorporating it into the main MTD code is a good idea.
I still think that having a lot of NOR flash erase cases means either HW
or SW design mistake. And striping might be not a really necessary thing
if the number of erase cases is small.
The implementation itself seems to be quite inmature and leaves a lot of
questions - starting from what command-line parameters do mean and
ending up with how it's supposed to work in a workload environment,
given the threads etc. etc. Maybe it slows down the performance of the
whole system, even though it does speed up the block erase.
Vitaly
next prev parent reply other threads:[~2006-03-21 15:54 UTC|newest]
Thread overview: 45+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-03-21 12:36 [PATCH/RFC] Linux MTD striping middle layer Belyakov, Alexander
2006-03-21 14:01 ` Vitaly Wool
2006-03-21 14:41 ` Alexander Belyakov
2006-03-21 15:11 ` Vitaly Wool [this message]
2006-03-22 9:36 ` Alexander Belyakov
2006-03-21 15:37 ` Jörn Engel
2006-03-21 16:37 ` Thomas Gleixner
2006-03-21 15:36 ` Nicolas Pitre
2006-03-21 15:09 ` Artem B. Bityutskiy
2006-03-21 18:11 ` Alexander Belyakov
2006-03-21 18:57 ` Artem B. Bityutskiy
2006-03-21 19:37 ` Nicolas Pitre
2006-03-21 20:24 ` Jörn Engel
2006-03-22 8:58 ` Artem B. Bityutskiy
2006-03-22 14:40 ` Alexander Belyakov
2006-03-22 14:47 ` Artem B. Bityutskiy
2006-03-22 15:10 ` Alexander Belyakov
2006-03-22 15:15 ` Artem B. Bityutskiy
2006-03-22 15:39 ` Alexander Belyakov
2006-03-22 15:45 ` Vitaly Wool
2006-03-22 16:23 ` Alexander Belyakov
2006-03-22 16:30 ` Artem B. Bityutskiy
2006-03-22 19:25 ` Vitaly Wool
2006-03-22 19:40 ` Nicolas Pitre
2006-03-23 10:10 ` Vitaly Wool
2006-03-22 15:51 ` Artem B. Bityutskiy
2006-03-22 9:39 ` Alexander Belyakov
2006-03-22 9:52 ` Artem B. Bityutskiy
2006-03-22 10:26 ` Alexander Belyakov
2006-03-22 10:51 ` Artem B. Bityutskiy
2006-03-22 13:35 ` Alexander Belyakov
2006-03-22 14:40 ` Artem B. Bityutskiy
2006-03-22 16:19 ` Artem B. Bityutskiy
2006-03-22 16:23 ` Artem B. Bityutskiy
2006-03-22 17:17 ` Nicolas Pitre
2006-03-22 17:28 ` Artem B. Bityutskiy
2006-03-22 17:50 ` Nicolas Pitre
2006-03-21 19:08 ` Artem B. Bityutskiy
2006-03-22 9:57 ` Alexander Belyakov
2006-03-22 10:23 ` Artem B. Bityutskiy
2006-03-22 17:08 ` Artem B. Bityutskiy
2006-03-22 17:23 ` Nicolas Pitre
2006-03-23 9:39 ` Alexander Belyakov
2006-03-23 14:23 ` Nicolas Pitre
2006-03-23 14:45 ` Alexander Belyakov
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=442017B0.4010508@ru.mvista.com \
--to=vwool@ru.mvista.com \
--cc=alexander.belyakov@intel.com \
--cc=alexey.korolev@intel.com \
--cc=linux-mtd@lists.infradead.org \
--cc=timofey.kutergin@intel.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox