Messages in this thread |  | | From | (Brad Pepers) | Subject | Re: Speeding up screen output for dialog | Date | Tue, 3 Sep 1996 16:56:17 -0600 (MDT) |
| |
> Date: Mon, 2 Sep 1996 09:57:33 +0200 (MET DST) > From: Bernd Schmidt <crux@pool.informatik.rwth-aachen.de> > > I've been wondering why some dialog-based applications > (e.g. menuconfig) take so long even on a P90 to draw the screen. So I > made some investigations with strace. I found that ncurses writes to > the screen in rather large blocks of bytes, but these get broken up > in write_chan() in n_tty.c into single byte writes to the console, > which is inefficient (I assume that setting the cursor after each > write is the most time-consuming part). So I came up with a hack: > Instead of calling opost() for each byte, I wrote a new function > opost_block() that examines the buffer and returns the number of > bytes that can be directly written. These are then passed to > con_write() instead of put_char(). > > You've defintiely identified a real problem in the slowness of the > console. However, the solution isn't really the best one, as it > requires that characters be read an extra time --- once in opost_block, > and once in the driver's write routine. When you consider that most > interrupt driven devices have to buffer characters themselves (what BSD > calls "pseudo-dma"), that means that there will be three copies, and > that's non-optimal.
I have written a patch for this which implements put_char() and flush_chars() for the console. It seems to work quite well. A test program that writes 4000 byte blocks at a time, 1000 times, takes about 9.5 seconds in my patched kernel and 55.8 in the old kernel. The only problem now is that I just grabbed 2.0.17 to make my patches against that and now my X server won't start (and of course I have it going straight to xdm from inittab so I get stuck). The X server starts but the monitor just can't seem to sync to the video signal (monitor is blank and all the lights are flashing!). Its a 21" Hitachi and the graphics card is a #9 Imagine 128 with 4Mb video RAM. I'm running a heavily modified Caldera system and the Accelerated-X server. I'm going to reverse the 2.0.17 patches until I can figure out what caused the problem...
Anyways - soon as I get my system up in a normal fashion I will post the patches. A couple questions while doing the patch:
1. I looked at the serial driver for how it does the buffering. It in one place defines the serial buffer as 4096 and the uses a page_alloc routine to get a page. Is it guarenteed in Linux that the page size will always be 4096 on all archs? I used kmalloc for now - does it have overhead (should I make the buffer a bit smaller than 4096)?
2. There seems to be a number of structs involved with virtual consoles. There is vc_cons and vt_cons and some others. I put the transmit buffer into vt_cons since I couldn't see much reason for either one. Anyone have an opinion which would be better?
3. I'm using a buffer of 4096 right now - too large? My guess is that it might as well be a full page.
> In the long run, opost() should probably be written so that it takes a > pointer, a from_user boolean, and a count. This will eliminate one of > the procedure activiations per character that's in the current system. > However, I think that fixing the console driver so that it supports > put_char() and flush_chars() will provide nearly all of the procedure > improvements you were looking for, while not impacting the performance > of the other tty drivers.
The changes do seem to make a big difference (about 5.9 times faster with large blocks) and its a fairly simple change.
> - Ted
====================================================================== Brad Pepers Proud supporter of Linux and Ramparts Management Group Ltd. Caldera in Canada! ramparts@agt.net http://www.agt.net/public/ramparts Linux rules!
|  |