a UBIFS image makes task pdflush blocked > 120 seconds

[Norbert van Bolhuis]

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.

Norbert.