"swiN: clock sio" process taking 75% CPU

[John Baldwin]

On Friday 21 July 2006 10:07, Gareth McCaughan wrote:
> 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.

Either 1 or 2 sounds like a good idea to me.  I think perhaps I
slightly favor 2, but not by much.  1 would probably be simpler.

-- 
John Baldwin