Am 20.10.2014 um 17:40 schrieb Artem Bityutskiy:
> Also, say, PEB X is in the work queue waiting for erasure. Fastmap comes
> along and saves it as "must be erased" in the fastmap. Fastmap finishes
> its job, PEB X gets erased, and I write my data there, so PEB X is
> referred to by LEB Y. Now I
Am 20.10.2014 um 18:09 schrieb Artem Bityutskiy:
> On Mon, 2014-10-20 at 17:59 +0200, Richard Weinberger wrote:
>>> Also, say, PEB X is in the work queue waiting for erasure. Fastmap comes
>>> along and saves it as "must be erased" in the fastmap. Fastmap finishes
>>> its job, PEB X gets erased,
On Mon, 2014-10-20 at 17:59 +0200, Richard Weinberger wrote:
> > Also, say, PEB X is in the work queue waiting for erasure. Fastmap comes
> > along and saves it as "must be erased" in the fastmap. Fastmap finishes
> > its job, PEB X gets erased, and I write my data there, so PEB X is
> > referred
Am 20.10.2014 um 17:40 schrieb Artem Bityutskiy:
> On Mon, 2014-10-20 at 17:17 +0200, Richard Weinberger wrote:
>>> That's just fastmap code not doing the right thing. We should not touch
>>> the work queue directly at all. What we _should_ do instead is to make
>>> it empty by asking the
On Mon, 2014-10-20 at 17:17 +0200, Richard Weinberger wrote:
> > That's just fastmap code not doing the right thing. We should not touch
> > the work queue directly at all. What we _should_ do instead is to make
> > it empty by asking the subsystem which manages it to flush it.
> >
> > 1. Lock
Am 20.10.2014 um 16:46 schrieb Artem Bityutskiy:
> On Thu, 2014-10-16 at 12:06 +0200, Richard Weinberger wrote:
>> Am 14.10.2014 um 12:23 schrieb Artem Bityutskiy:
>>> On Mon, 2014-10-13 at 23:04 +0200, Richard Weinberger wrote:
Am 13.10.2014 um 17:23 schrieb Artem Bityutskiy:
> Well,
On Thu, 2014-10-16 at 12:06 +0200, Richard Weinberger wrote:
> Am 14.10.2014 um 12:23 schrieb Artem Bityutskiy:
> > On Mon, 2014-10-13 at 23:04 +0200, Richard Weinberger wrote:
> >> Am 13.10.2014 um 17:23 schrieb Artem Bityutskiy:
> >>> Well, used and free are RB-trees, looking them up is slow.
>
On Thu, 2014-10-16 at 12:06 +0200, Richard Weinberger wrote:
Am 14.10.2014 um 12:23 schrieb Artem Bityutskiy:
On Mon, 2014-10-13 at 23:04 +0200, Richard Weinberger wrote:
Am 13.10.2014 um 17:23 schrieb Artem Bityutskiy:
Well, used and free are RB-trees, looking them up is slow.
This is
Am 20.10.2014 um 16:46 schrieb Artem Bityutskiy:
On Thu, 2014-10-16 at 12:06 +0200, Richard Weinberger wrote:
Am 14.10.2014 um 12:23 schrieb Artem Bityutskiy:
On Mon, 2014-10-13 at 23:04 +0200, Richard Weinberger wrote:
Am 13.10.2014 um 17:23 schrieb Artem Bityutskiy:
Well, used and free are
On Mon, 2014-10-20 at 17:17 +0200, Richard Weinberger wrote:
That's just fastmap code not doing the right thing. We should not touch
the work queue directly at all. What we _should_ do instead is to make
it empty by asking the subsystem which manages it to flush it.
1. Lock the work
Am 20.10.2014 um 17:40 schrieb Artem Bityutskiy:
On Mon, 2014-10-20 at 17:17 +0200, Richard Weinberger wrote:
That's just fastmap code not doing the right thing. We should not touch
the work queue directly at all. What we _should_ do instead is to make
it empty by asking the subsystem which
On Mon, 2014-10-20 at 17:59 +0200, Richard Weinberger wrote:
Also, say, PEB X is in the work queue waiting for erasure. Fastmap comes
along and saves it as must be erased in the fastmap. Fastmap finishes
its job, PEB X gets erased, and I write my data there, so PEB X is
referred to by LEB
Am 20.10.2014 um 18:09 schrieb Artem Bityutskiy:
On Mon, 2014-10-20 at 17:59 +0200, Richard Weinberger wrote:
Also, say, PEB X is in the work queue waiting for erasure. Fastmap comes
along and saves it as must be erased in the fastmap. Fastmap finishes
its job, PEB X gets erased, and I write
Am 20.10.2014 um 17:40 schrieb Artem Bityutskiy:
Also, say, PEB X is in the work queue waiting for erasure. Fastmap comes
along and saves it as must be erased in the fastmap. Fastmap finishes
its job, PEB X gets erased, and I write my data there, so PEB X is
referred to by LEB Y. Now I have
Am 16.10.2014 um 12:15 schrieb Artem Bityutskiy:
> On Thu, 2014-10-16 at 12:06 +0200, Richard Weinberger wrote:
>> What I'm trying to say is, state tracking would solve the "internal state
>> accessing" problem in a clean and
>> sane way.
>
> Can you squeeze the stat to the lookup talbe? It
On Thu, 2014-10-16 at 12:06 +0200, Richard Weinberger wrote:
> What I'm trying to say is, state tracking would solve the "internal state
> accessing" problem in a clean and
> sane way.
Can you squeeze the stat to the lookup talbe? It contains pointers, so
the last 2 bits could be used for the
Am 14.10.2014 um 12:23 schrieb Artem Bityutskiy:
> On Mon, 2014-10-13 at 23:04 +0200, Richard Weinberger wrote:
>> Am 13.10.2014 um 17:23 schrieb Artem Bityutskiy:
>>> Well, used and free are RB-trees, looking them up is slow.
>>
>> This is true but we'd have to look it up in multiple trees and
Am 14.10.2014 um 12:23 schrieb Artem Bityutskiy:
On Mon, 2014-10-13 at 23:04 +0200, Richard Weinberger wrote:
Am 13.10.2014 um 17:23 schrieb Artem Bityutskiy:
Well, used and free are RB-trees, looking them up is slow.
This is true but we'd have to look it up in multiple trees and the
On Thu, 2014-10-16 at 12:06 +0200, Richard Weinberger wrote:
What I'm trying to say is, state tracking would solve the internal state
accessing problem in a clean and
sane way.
Can you squeeze the stat to the lookup talbe? It contains pointers, so
the last 2 bits could be used for the state.
Am 16.10.2014 um 12:15 schrieb Artem Bityutskiy:
On Thu, 2014-10-16 at 12:06 +0200, Richard Weinberger wrote:
What I'm trying to say is, state tracking would solve the internal state
accessing problem in a clean and
sane way.
Can you squeeze the stat to the lookup talbe? It contains
On 10/14/2014 4:02 PM, Artem Bityutskiy wrote:
On Tue, 2014-10-14 at 15:21 +0300, Tanya Brokhman wrote:
Hi Artem/Richard
I think your discussion here stopped being relevant to this specific
patch but went on to the fastmap feature design in general :)
This patch fixes a real bug in the current
On Tue, 2014-10-14 at 15:21 +0300, Tanya Brokhman wrote:
> Hi Artem/Richard
>
> I think your discussion here stopped being relevant to this specific
> patch but went on to the fastmap feature design in general :)
> This patch fixes a real bug in the current implementation of the
> feature. What
On 10/14/2014 1:23 PM, Artem Bityutskiy wrote:
On Mon, 2014-10-13 at 23:04 +0200, Richard Weinberger wrote:
Am 13.10.2014 um 17:23 schrieb Artem Bityutskiy:
Well, used and free are RB-trees, looking them up is slow.
This is true but we'd have to look it up in multiple trees and the
On Mon, 2014-10-13 at 23:04 +0200, Richard Weinberger wrote:
> Am 13.10.2014 um 17:23 schrieb Artem Bityutskiy:
> > Well, used and free are RB-trees, looking them up is slow.
>
> This is true but we'd have to look it up in multiple trees and the protection
> queue...
Right. 2 RB-trees, and one
On Mon, 2014-10-13 at 23:04 +0200, Richard Weinberger wrote:
Am 13.10.2014 um 17:23 schrieb Artem Bityutskiy:
Well, used and free are RB-trees, looking them up is slow.
This is true but we'd have to look it up in multiple trees and the protection
queue...
Right. 2 RB-trees, and one list.
On 10/14/2014 1:23 PM, Artem Bityutskiy wrote:
On Mon, 2014-10-13 at 23:04 +0200, Richard Weinberger wrote:
Am 13.10.2014 um 17:23 schrieb Artem Bityutskiy:
Well, used and free are RB-trees, looking them up is slow.
This is true but we'd have to look it up in multiple trees and the
On Tue, 2014-10-14 at 15:21 +0300, Tanya Brokhman wrote:
Hi Artem/Richard
I think your discussion here stopped being relevant to this specific
patch but went on to the fastmap feature design in general :)
This patch fixes a real bug in the current implementation of the
feature. What
On 10/14/2014 4:02 PM, Artem Bityutskiy wrote:
On Tue, 2014-10-14 at 15:21 +0300, Tanya Brokhman wrote:
Hi Artem/Richard
I think your discussion here stopped being relevant to this specific
patch but went on to the fastmap feature design in general :)
This patch fixes a real bug in the current
Am 13.10.2014 um 17:23 schrieb Artem Bityutskiy:
> Well, used and free are RB-trees, looking them up is slow.
This is true but we'd have to look it up in multiple trees and the protection
queue...
> If what you need is to go through all used and free PEBs, then you can
> introduce some kind of
On Mon, 2014-10-13 at 18:23 +0300, Artem Bityutskiy wrote:
> > The interface would work but some work in wl.c is needed.
> > For example if I want to find out in which state PEB 1 is wl.c would have to
> > look int free free, used free, protection queue, etc.. to tell me the
> > state. This is
On Mon, 2014-10-13 at 16:30 +0200, Richard Weinberger wrote:
> Am 13.10.2014 um 15:17 schrieb Artem Bityutskiy:
> > On Fri, 2014-10-03 at 21:06 +0200, Richard Weinberger wrote:
> >> Fastmap needs basically access to all internal state of UBI, which
> >> lives mostly
> >> within wl.c
> >
> >
Am 13.10.2014 um 15:17 schrieb Artem Bityutskiy:
> On Fri, 2014-10-03 at 21:06 +0200, Richard Weinberger wrote:
>> Fastmap needs basically access to all internal state of UBI, which
>> lives mostly
>> within wl.c
>
> Sounds like a very strong assertion, smells a bit fishy, need the
> details.
On Fri, 2014-10-03 at 21:06 +0200, Richard Weinberger wrote:
> Fastmap needs basically access to all internal state of UBI, which
> lives mostly
> within wl.c
Sounds like a very strong assertion, smells a bit fishy, need the
details.
> It needs to iterate over the used, free, erase, scrub
On Fri, 2014-10-03 at 21:06 +0200, Richard Weinberger wrote:
Fastmap needs basically access to all internal state of UBI, which
lives mostly
within wl.c
Sounds like a very strong assertion, smells a bit fishy, need the
details.
It needs to iterate over the used, free, erase, scrub RB-trees,
Am 13.10.2014 um 15:17 schrieb Artem Bityutskiy:
On Fri, 2014-10-03 at 21:06 +0200, Richard Weinberger wrote:
Fastmap needs basically access to all internal state of UBI, which
lives mostly
within wl.c
Sounds like a very strong assertion, smells a bit fishy, need the
details.
Fastmap need
On Mon, 2014-10-13 at 16:30 +0200, Richard Weinberger wrote:
Am 13.10.2014 um 15:17 schrieb Artem Bityutskiy:
On Fri, 2014-10-03 at 21:06 +0200, Richard Weinberger wrote:
Fastmap needs basically access to all internal state of UBI, which
lives mostly
within wl.c
Sounds like a very
On Mon, 2014-10-13 at 18:23 +0300, Artem Bityutskiy wrote:
The interface would work but some work in wl.c is needed.
For example if I want to find out in which state PEB 1 is wl.c would have to
look int free free, used free, protection queue, etc.. to tell me the
state. This is slow.
Am 13.10.2014 um 17:23 schrieb Artem Bityutskiy:
Well, used and free are RB-trees, looking them up is slow.
This is true but we'd have to look it up in multiple trees and the protection
queue...
If what you need is to go through all used and free PEBs, then you can
introduce some kind of
Am 03.10.2014 16:31, schrieb Artem Bityutskiy:
> On Tue, 2014-09-30 at 00:20 +0200, Richard Weinberger wrote:
>> +
>> +for (i = 0; i < UBI_PROT_QUEUE_LEN; i++) {
>> +list_for_each_entry(wl_e, >pq[i], u.list) {
>> +fec = (struct ubi_fm_ec *)(fm_raw + fm_pos);
>
On Tue, 2014-09-30 at 00:20 +0200, Richard Weinberger wrote:
> +
> + for (i = 0; i < UBI_PROT_QUEUE_LEN; i++) {
> + list_for_each_entry(wl_e, >pq[i], u.list) {
> + fec = (struct ubi_fm_ec *)(fm_raw + fm_pos);
Similarly to my other posts, is it possible to not
On Tue, 2014-09-30 at 00:20 +0200, Richard Weinberger wrote:
+
+ for (i = 0; i UBI_PROT_QUEUE_LEN; i++) {
+ list_for_each_entry(wl_e, ubi-pq[i], u.list) {
+ fec = (struct ubi_fm_ec *)(fm_raw + fm_pos);
Similarly to my other posts, is it possible to not
Am 03.10.2014 16:31, schrieb Artem Bityutskiy:
On Tue, 2014-09-30 at 00:20 +0200, Richard Weinberger wrote:
+
+for (i = 0; i UBI_PROT_QUEUE_LEN; i++) {
+list_for_each_entry(wl_e, ubi-pq[i], u.list) {
+fec = (struct ubi_fm_ec *)(fm_raw + fm_pos);
On 10/2/2014 4:32 PM, Richard Weinberger wrote:
Am 02.10.2014 15:28, schrieb Tanya Brokhman:
Hi Richard
On 9/30/2014 1:20 AM, Richard Weinberger wrote:
Fastmap can miss a PEB if it is in the protection queue
and not jet in the used tree.
Treat every protected PEB as used.
Signed-off-by:
Am 02.10.2014 15:28, schrieb Tanya Brokhman:
> Hi Richard
>
> On 9/30/2014 1:20 AM, Richard Weinberger wrote:
>> Fastmap can miss a PEB if it is in the protection queue
>> and not jet in the used tree.
>> Treat every protected PEB as used.
>>
>> Signed-off-by: Richard Weinberger
>> ---
>>
Hi Richard
On 9/30/2014 1:20 AM, Richard Weinberger wrote:
Fastmap can miss a PEB if it is in the protection queue
and not jet in the used tree.
Treat every protected PEB as used.
Signed-off-by: Richard Weinberger
---
drivers/mtd/ubi/fastmap.c | 13 +
1 file changed, 13
Hi Richard
On 9/30/2014 1:20 AM, Richard Weinberger wrote:
Fastmap can miss a PEB if it is in the protection queue
and not jet in the used tree.
Treat every protected PEB as used.
Signed-off-by: Richard Weinberger rich...@nod.at
---
drivers/mtd/ubi/fastmap.c | 13 +
1 file
Am 02.10.2014 15:28, schrieb Tanya Brokhman:
Hi Richard
On 9/30/2014 1:20 AM, Richard Weinberger wrote:
Fastmap can miss a PEB if it is in the protection queue
and not jet in the used tree.
Treat every protected PEB as used.
Signed-off-by: Richard Weinberger rich...@nod.at
---
On 10/2/2014 4:32 PM, Richard Weinberger wrote:
Am 02.10.2014 15:28, schrieb Tanya Brokhman:
Hi Richard
On 9/30/2014 1:20 AM, Richard Weinberger wrote:
Fastmap can miss a PEB if it is in the protection queue
and not jet in the used tree.
Treat every protected PEB as used.
Signed-off-by:
Fastmap can miss a PEB if it is in the protection queue
and not jet in the used tree.
Treat every protected PEB as used.
Signed-off-by: Richard Weinberger
---
drivers/mtd/ubi/fastmap.c | 13 +
1 file changed, 13 insertions(+)
diff --git a/drivers/mtd/ubi/fastmap.c
Fastmap can miss a PEB if it is in the protection queue
and not jet in the used tree.
Treat every protected PEB as used.
Signed-off-by: Richard Weinberger rich...@nod.at
---
drivers/mtd/ubi/fastmap.c | 13 +
1 file changed, 13 insertions(+)
diff --git a/drivers/mtd/ubi/fastmap.c
50 matches
Mail list logo
