a UBIFS image makes task pdflush blocked > 120 seconds

Quoted 8 lines

Fair enough. However, this is not UBI/UBIFS which blocks everything. This MTD chip lock that locks everything and is contended at. The right fix would be improve MTD/CFI and teach them to be asynchronous and drop the chip lock while the eraseing is in progress, allowing other tasks to do I/O on other blocks. However, I do not know is it possible at all.

Quoted 9 lines

I mean, how UBI/UBIFS can help when:

1. Erase takes long time (how long? 0.2-0.5 sec?)
2. There are huge number of eraseblocks to erase in the queue.
3. All I/O is contended on one locks, and everything block while one eraseblock is erased.

How can UBI/UBIFS make things really fly fast?

true, UBI/UBIFS can't really fix this.
Btw. the sector erase time for our NOR flash (S29GL01GP) is 0.7-0.8 seconds.

Quoted 9 lines

The only way to help from UBI side I see is to lessen the UBI background thread's priority - you could try this. Or for the background formatting, have a 'yield()' call in the UBI background thread.

Or we could have a 'nor_erase_quirk()' in the UBI background thread, which would call yield() if the previous operation was "erase", and the next one is also "erase". You could try this.

Do you have any other suggestions?

No. Let's try the 'nor_erase_quirk()' solution.
yield() will send the current process to expired list which means the other processes will be activated for sure, right ? I think this will work fine.
It sounds like you already have an idea how to implement this, can you send a patch ? I will test it.

The best solution is to use erase-suspend (if your chip supports it). Our chip supports read+write erase-suspend (cfip->EraseSuspend = 0x2). But as Joakim already mentioned cfi_cmdset_0002.c disables erase-suspend for writing. Maybe this is because of line 710 in the below code:

703 if (mode == FL_WRITING) /* FIXME:
Erase-suspend-program appears broken. */
704 goto sleep;
705
706 if (!( mode == FL_READY

  707                       || mode == FL_POINT
  708                       || !cfip
  709                       || (mode == FL_WRITING &&

(cfip->EraseSuspend & 0x2))
710 || (mode == FL_WRITING &&
(cfip->EraseSuspend & 0x1)
711 )))
712 goto sleep;
713
714 /* We could check to see if we're trying to access
the sector

As has been mentioned earlier line 710 should probably be removed. Erase-suspend shouldn't be done if read-only erase-suspend is supported (cfip->EraseSuspend = 0x1).

I can remove line 703-705 + 710 and test this.
I wonder though, if this works, is this enough "solid ground" to enable erase-suspend for cmdset_002 ?

Quoted 9 lines

The only way to help from UBI side I see is to lessen the UBI background thread's priority - you could try this. Or for the background formatting, have a 'yield()' call in the UBI background thread.

Or we could have a 'nor_erase_quirk()' in the UBI background thread, which would call yield() if the previous operation was "erase", and the next one is also "erase". You could try this.

Do you have any other suggestions?

No. Let's try the 'nor_erase_quirk()' solution.

I tested all mentioned solutions. It turns out only the "erase-suspend option" helps.

lowering the UBI BG task priority somehow causes the application to block until the UBI BG task finishes erasing *all* NOR blocks. I guess the application is blocked in get_chip and never gets activated by the scheduler.
I do not understand why this happens. How can a lower UBI BG prio make the application block for so long ?
Maybe I implemented it wrong, I added line 1359.
1354 int ubi_thread(void *u)
1355 {
1356 int failures = 0;
1357 struct ubi_device *ubi = u;
1358
1359 set_user_nice(current, 19);
1360
1361 ubi_msg("background thread \"%s\" started, PID %d",
1362 ubi->bgt_name, task_pid_nr(current));
I did see the ubi_bg prio = 139 (lowest possible prio), it used to be 115. I also tried 135, same result.
Anyway, this doesn't seem to work.

Using yield() in the UBI BG task doesn't seem to do much. It for sure doesn't cause the application to become active after a (couple of) erase operations. The log shows:
LE:0197, TIME=0026.276, pid=0918, M(xy=00)=do_erase_oneblock, START LE:0198, TIME=0026.868, pid=1237, M(xy=04)=commit_semR, make_reservation, Req DOWN 1 LE:0199, TIME=0026.868, pid=1237, M(xy=05)=commit_semR, make_reservation, DOWN 1 LE:0200, TIME=0026.868, pid=1237, M(xy=02)=io_mutex, reserve_space, Req LOCK 1 LE:0201, TIME=0026.868, pid=1237, M(xy=03)=io_mutex, reserve_space, LOCK 1 LE:0202, TIME=0027.104, pid=0918, M(xy=01)=do_erase_oneblock, END
LE:0203, TIME=0027.104, pid=0918, M(xy=0c)=yield
LE:0204, TIME=0027.104, pid=0918, M(xy=00)=do_erase_oneblock, START LE:0205, TIME=0027.876, pid=0918, M(xy=01)=do_erase_oneblock, END
LE:0206, TIME=0027.876, pid=0918, M(xy=0c)=yield
LE:0207, TIME=0027.876, pid=0918, M(xy=00)=do_erase_oneblock, START LE:0208, TIME=0028.672, pid=0918, M(xy=01)=do_erase_oneblock, END
LE:0209, TIME=0028.672, pid=0918, M(xy=0c)=yield
<omitted many do_erase_oneblock END/START + yield entries>
LE:0294, TIME=0051.132, pid=0918, M(xy=00)=do_erase_oneblock, START LE:0295, TIME=0051.944, pid=0918, M(xy=01)=do_erase_oneblock, END
LE:0296, TIME=0051.944, pid=0918, M(xy=0c)=yield
LE:0297, TIME=0051.944, pid=0918, M(xy=00)=do_erase_oneblock, START LE:0298, TIME=0052.080, pid=0108, M(xy=04)=commit_semR, make_reservation, Req DOWN 1 LE:0299, TIME=0052.080, pid=0108, M(xy=05)=commit_semR, make_reservation, DOWN 1 LE:0300, TIME=0052.080, pid=0108, M(xy=02)=io_mutex, reserve_space, Req LOCK 1
<omitted many do_erase_oneblock END/START + yield entries>
LE:0405, TIME=0080.652, pid=0918, M(xy=00)=do_erase_oneblock, START LE:0406, TIME=0081.536, pid=0918, M(xy=01)=do_erase_oneblock, END
LE:0407, TIME=0081.536, pid=0918, M(xy=0c)=yield
LE:0408, TIME=0081.536, pid=0918, M(xy=00)=do_erase_oneblock, START LE:0409, TIME=0082.332, pid=0918, M(xy=01)=do_erase_oneblock, END
LE:0410, TIME=0082.332, pid=0918, M(xy=0c)=yield
LE:0411, TIME=0082.332, pid=1237, M(xy=06)=io_mutex, release_head, Req UNLOCK LE:0412, TIME=0082.332, pid=0108, M(xy=03)=io_mutex, reserve_space, LOCK 1 LE:0413, TIME=0082.332, pid=0108, M(xy=06)=io_mutex, release_head, Req UNLOCK LE:0414, TIME=0082.332, pid=0108, M(xy=07)=io_mutex, release_head, UNLOCK LE:0415, TIME=0082.332, pid=0108, M(xy=08)=commit_semR, finish_reservation, Req UP LE:0416, TIME=0082.332, pid=0108, M(xy=09)=commit_semR, finish_reservation, UP As can be seen it still takes ~ 55 seconds before the application (pid=1237) and pdflush (pid=0108) can continue.

Using the erase-suspend feature works great. The application creates and writes files without any delay. pdflush isn't delayed either.
The difference is that the UBI BG thread erased only 200 blocks after our application is completely up and running while this used to be ~ 1000. This is as expected and a logical consequence of the erase-suspend.

So as far as I'm concerned this problem has been solved. I'm gonna use the erase-suspend feature in the way Joakim suggested.
I will do a few additional erase-suspend related tests (since it looks like I'm one of the first users for cmdset_002) and report problems to this list (as usual).

thanks for all help.

The best way to say thanks is:

1. Add a small documentation section about your case to UBIFS howto, so others could benefit. You could send a patch against the MTD web-site:
http://git.infradead.org/mtd-www.git

2. Make your solution work in upstream out-of-the box.

Quoted 7 lines · Artem Bityutskiy

The best way to say thanks is:

1. Add a small documentation section about your case to UBIFS howto, so others could benefit. You could send a patch against the MTD web-site:
http://git.infradead.org/mtd-www.git

Ok, I'll do this.

Quoted 2 lines

2. Make your solution work in upstream out-of-the box.

The solution is to enable erase-suspend for writing for which Joakim already sent earlier patches.
So if it's OK with him I will send the patch for cmdset_0002.

Quoted 10 lines

Quoted 7 lines · Artem Bityutskiy

The best way to say thanks is:

1. Add a small documentation section about your case to UBIFS howto, so others could benefit. You could send a patch against the MTD web-site:
http://git.infradead.org/mtd-www.git

Quoted 1 line

Ok, I'll do this.

Cool. I guess a section to this page would work well:
http://www.linux-mtd.infradead.org/faq/ubifs.html

Quoted 6 lines

Quoted 2 lines

2. Make your solution work in upstream out-of-the box.

The solution is to enable erase-suspend for writing for which Joakim already sent earlier patches.
So if it's OK with him I will send the patch for cmdset_0002.

Why his patch is not in upstream yet? I think he mentioned some issues with modules.

Artem Bityutskiy <[email protected]> wrote on 18/11/2009 10:40:24:

Quoted 12 lines · Norbert van Bolhuis

Quoted 10 lines

Quoted 7 lines · Artem Bityutskiy

The best way to say thanks is:

1. Add a small documentation section about your case to UBIFS howto, so others could benefit. You could send a patch against the MTD web-site:
http://git.infradead.org/mtd-www.git

Quoted 11 lines

Quoted 1 line

Ok, I'll do this.

Cool. I guess a section to this page would work well:
http://www.linux-mtd.infradead.org/faq/ubifs.html

Quoted 6 lines

Quoted 2 lines

2. Make your solution work in upstream out-of-the box.

The solution is to enable erase-suspend for writing for which Joakim already sent earlier patches.
So if it's OK with him I will send the patch for cmdset_0002.

I am fine with that, I sent them earlier because I wanted someone with cmdset_0002 to pick them up, test and submit.

Quoted 3 lines

Why his patch is not in upstream yet? I think he mentioned some issues with modules.

Nope, that was a another JFFS2 issue. Not related to this.

Quoted 7 lines

Quoted 4 lines

Quoted 4 lines

Quoted 1 line

The solution is to enable erase-suspend for writing for which Joakim already sent earlier patches.
So if it's OK with him I will send the patch for cmdset_0002.

I am fine with that, I sent them earlier because I wanted someone with cmdset_0002 to pick them up, test and submit.

Quoted 3 lines

Quoted 2 lines

Why his patch is not in upstream yet? I think he mentioned some issues with modules.

Nope, that was a another JFFS2 issue. Not related to this.

I'm do not know CFI, but if you or Norbet re-submit the patch with CC to Nicolas, put some good description which problems it solves, tell that you tested it, I can help merging it by putting it to my l2-mtd-2.6.git.

Quoted 29 lines

Artem Bityutskiy <[email protected]> wrote on 18/11/2009 10:40:24:

Quoted 12 lines · Norbert van Bolhuis

Quoted 10 lines

Quoted 7 lines · Artem Bityutskiy

The best way to say thanks is:

1. Add a small documentation section about your case to UBIFS howto, so others could benefit. You could send a patch against the MTD web-site:
http://git.infradead.org/mtd-www.git

Quoted 11 lines

Quoted 1 line

Ok, I'll do this.

Cool. I guess a section to this page would work well:
http://www.linux-mtd.infradead.org/faq/ubifs.html

Quoted 6 lines

Quoted 2 lines

2. Make your solution work in upstream out-of-the box.

The solution is to enable erase-suspend for writing for which Joakim already sent earlier patches.
So if it's OK with him I will send the patch for cmdset_0002.

I am fine with that, I sent them earlier because I wanted someone with cmdset_0002 to pick them up, test and submit.

Quoted 1 line

Quoted 4 lines

Quoted 2 lines

Why his patch is not in upstream yet? I think he mentioned some issues with modules.

Nope, that was a another JFFS2 issue. Not related to this.

I'm do not know CFI, but if you or Norbet re-submit the patch with CC to Nicolas, put some good description which problems it solves, tell that you tested it, I can help merging it by putting it to my l2-mtd-2.6.git.