"swiN: clock sio" process taking 75% CPU

[Gareth McCaughan]

On Wednesday 2006-07-19 18:36, John Baldwin wrote:
> On Wednesday 19 July 2006 12:11, Gareth McCaughan wrote:
> > (The particular screen saver I turned on was the one called
> > "warp"; I haven't checked yet whether others have the same
> > CPU-guzzling effect.)
> 
> Actually, if you could test that, that would be helpful as that would
> narrow down where the bug is (syscons vs. the specific screen saver).

OK, so here's what's happening.

1. On my machine, every call to vesa_set_origin takes about 0.2ms;
   about 0.1ms in each of two calls to int 10h, code 4f/05, which
   is the bank switching VESA VBE BIOS call.

2. The "fire" and "star" screen savers make rather a lot of calls
   to set_origin, which on my machine gets handled by vesa_set_origin.
   For instance, fire_saver.c *always* performs at least one call
   per screen row. On the box in question, the screen is in a 320x200x1byte
   mode, so there are 200 bank switches even though the entire screen
   sits within a single bank!

3. With "fire", I get about 10 updates per second, each calling
   set_origin 200 times, for a total of about 2000*0.2ms = 0.4s
   per second. In other words, about half my CPU. Ouch.

Suggestions:

1. Make vesa_set_origin remember the last origin it was given
   and do nothing if it's being asked for the same origin again.
   Two ways: put a field in video_adapter_t, or -- easier and
   more localized but rather icky -- make vesa_set_origin remember
   the last (origin,adapter) pair it was fed and do nothing only
   if both elements are the same. I'm assuming that there aren't
   any circumstances in which the origin can be changed *between*
   vesa_set_origin calls.

2. If #1 is a bad idea for some reason, make the syscons screen
   savers that call set_origin remember what origin they set.
   This would also need to be per-adapter if it has to persist
   between updates; but it would probably suffice just to avoid
   gratuitous repeated set_origin calls *within* a single update.

3. Regardless of whether #1 or #2 is done, it might be wise to
   keep track of how much time is spent running syscons screen savers
   and slow down the update rate if it's more than (say) 10%.

If any of these is thought a good idea, I can provide a patch.

-- 
g