Date: Fri, 21 Jul 2006 15:07:01 +0100 From: Gareth McCaughan <gmccaughan@synaptics-uk.com> To: freebsd-hackers@freebsd.org Subject: Re: "swiN: clock sio" process taking 75% CPU Message-ID: <200607211507.02139.gmccaughan@synaptics-uk.com> In-Reply-To: <200607191336.54880.jhb@freebsd.org> References: <200607181317.33416.gmccaughan@synaptics-uk.com> <200607191711.11966.gmccaughan@synaptics-uk.com> <200607191336.54880.jhb@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200607211507.02139.gmccaughan>