Messages in this thread Patch in this message | | | Date | Thu, 10 Dec 1998 13:54:50 +0300 | From | "Alexander V. Lukyanov" <> | Subject | scrolling eats too much cpu (2) |
| |
Hi!
I'm investigating why fbcon scrolling eats too much cpu, and even real-time tasks start to starve. The problem was seen on Sparc Station 5, which is not too fast. Kernel 2.1.130 from cvs.
I have found out that:
1. do_con_write (console.c) writes the whole block and does not schedule. 2. write_chan (n_tty.c) in OPOST mode writes the whole block and does not schedule.
So, when a program writes large blocks to graphical console (e.g. telnet or cat), scheduling does not occur quite a long time.
I tried the following hack, and it helped in -opost case. But I know it's not correct solution. Any ideas?
--- /home/lav/linux/kernel/vger-cvs/linux/drivers/char/console.c Mon Nov 9 01:28:28 1998 +++ console.c Thu Dec 10 13:38:28 1998 @@ -1776,6 +1776,8 @@ unsigned long draw_from = 0, draw_to = 0; struct vt_struct *vt = (struct vt_struct *)tty->driver_data; u16 himask, charmask; + /* don't allow console take too much time */ + unsigned long time_limit = jiffies + HZ/50; currcons = vt->vc_num; if (!vc_cons_allocated(currcons)) { @@ -1912,6 +1914,14 @@ } FLUSH do_con_trol(tty, currcons, c); + + /* This does not count that get_user can sleep */ + if (time_after(jiffies, time_limit)) + { + current->counter=0; + current->state=TASK_RUNNING; /* restart immediately */ + break; + } } FLUSH enable_bh(CONSOLE_BH); Alexander.
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |