All of lore.kernel.org
 help / color / mirror / Atom feed
From: Vitaly Wool <vwool@ru.mvista.com>
To: Nicolas Pitre <npitre@mvista.com>
Cc: Alexander Belyakov <alexander.belyakov@intel.com>,
	linux-mtd@lists.infradead.org, "Kutergin,
	Timofey" <timofey.kutergin@intel.com>,
	"Korolev, Alexey" <alexey.korolev@intel.com>
Subject: Re: [PATCH/RFC] Linux MTD striping middle layer
Date: Thu, 23 Mar 2006 13:10:21 +0300	[thread overview]
Message-ID: <4422740D.9080506@ru.mvista.com> (raw)
In-Reply-To: <Pine.LNX.4.64.0603221428480.3631@localhost.localdomain>

Nicolas Pitre wrote:

>>Let's look at it at the following angle. Striping is a nice concept, as well
>>as many other nice concepts that exist in the world. Are they all worth being
>>impemented in Linux MTD subsystem? :)
>>    
>>
>
>Why not, if you can configure it out.
>  
>
Well, the thing is it's getting more and more complicated and harder to 
support...

>  
>
>>OTOH, what is the rationale? Make devices operate faster. Okay, why can't this
>>be implemented as mtdconcat optimization?
>>    
>>
>
>mtdconcat provides linear access to subdevices.
>
>The stripe module provides _interleaved_ access to subdevices.
>
>That is the fundamental difference.
>  
>
Let's make a config option to mtdconcat  switching between 
interleaved/linear access. Why not?

>  
>
>>What I'd also like to say is that having a lot of threads doesn't look
>>attractive to me.
>>    
>>
>
>What is the problem with threads?  The kernel already uses them heavily 
>for many purposes because it makes things cleaner.
>  
>
More threads = more overhead, more context switching, more possibilities 
to  decrease the system performance (wrong prio choice, prio inversion 
etc.).
Adding, say, 5 more threads (which doesn't look impossible wrt to this 
implementation) doesn't look good.

>  
>
>>I'd rather go in for changing the whole MTD subsystem to
>>make the API asynchoronus, and then you won't need many threads. But this is a
>>rather dramatic change...
>>    
>>
>
>But do you realize that any asynchronous implementation will _still_ 
>require kernel threads of its own to do the work anyway?  That's the 
>reason why there is so many kernel threads running in your kernel 
>already.
>  
>
Yes, but not necessarily so many of. I can even think of the following 
implementation (roughly):

- erase: issue a command to erase the block from 1st chip, issue command 
to erase the block from 2nd chip, wait on counting semaphore;
(this is happening in caller context)
- hrm, 2 callbacks on erase completion, increasing the semaphore counter 
(1 thread needed)

Vitaly

  reply	other threads:[~2006-03-23 10:10 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
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 [this message]
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=4422740D.9080506@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=npitre@mvista.com \
    --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 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.