public inbox for linux-mtd@lists.infradead.org
 help / color / mirror / Atom feed
From: "zhao, forrest" <forrest.zhao@intel.com>
To: "Artem B. Bityutskiy" <dedekind@yandex.ru>
Cc: linux-mtd@lists.infradead.org
Subject: Re: The problem that I didn't think out
Date: Mon, 28 Nov 2005 10:20:58 +0800	[thread overview]
Message-ID: <1133144458.3156.15.camel@localhost.localdomain> (raw)
In-Reply-To: <4386FC5F.9050305@yandex.ru>


> > If we store the erase block usage information in a file on flash,
> > we need to sort it in RAM in order to find the dirtiest one.
> > Then this sort operation is O(N), N is the number of erase blocks.
> > Also the memory consumed by this sorted data structure is O(N).
> We may devide this file on constant-size chunks, and search only one 
> chunk at a time. And we may have a list of 10 most worn out eraseblocks 
> and keep it in the superblock. So the scalability will be O(1) IMO.
> 
I think keeping track of a list of 10 most worn out eraseblocks
is hard to be O(1) since this list is changed dynamically.
In particular, we need to recalculate the list after every update
operation; in order to recalculate the list we need to keep the usage
information of all erase blocks in RAM in sorted manner. So if this is
the case, the RAM occupation is O(N).


> > I used to think that we could put the sorted data structure on flash,
> > but this will incur enormous update operations.
> Enormous? This needs measuring and evaluating. Let's create a user-level 
> prototype and see.

Agree. We need to do much measuring, evaluating and comparing work
before achieving the final design decision.
Do you have a time table for the user-level prototype? I think I can
give my contribution to it.


Thanks,
Forrest

  parent reply	other threads:[~2005-11-28  2:26 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-11-25  8:36 The problem that I didn't think out Zhao, Forrest
2005-11-25 11:58 ` Artem B. Bityutskiy
2005-11-27 13:01   ` Ferenc Havasi
2005-11-27 13:20     ` Artem B. Bityutskiy
2005-11-28  0:32       ` Ferenc Havasi
2005-11-28 10:15         ` Artem B. Bityutskiy
2005-11-28  2:20   ` zhao, forrest [this message]
2005-11-28 10:24     ` Artem B. Bityutskiy

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=1133144458.3156.15.camel@localhost.localdomain \
    --to=forrest.zhao@intel.com \
    --cc=dedekind@yandex.ru \
    --cc=linux-mtd@lists.infradead.org \
    /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