From owner-freebsd-hackers@FreeBSD.ORG Fri Jul 21 16:04:16 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C884916A4DA for ; Fri, 21 Jul 2006 16:04:16 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (66-23-211-162.clients.speedfactory.net [66.23.211.162]) by mx1.FreeBSD.org (Postfix) with ESMTP id E9B7A43D46 for ; Fri, 21 Jul 2006 16:04:11 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from zion.baldwin.cx (zion.baldwin.cx [192.168.0.7]) (authenticated bits=0) by server.baldwin.cx (8.13.4/8.13.4) with ESMTP id k6LG48FV099200; Fri, 21 Jul 2006 12:04:10 -0400 (EDT) (envelope-from jhb@freebsd.org) From: John Baldwin To: Gareth McCaughan Date: Fri, 21 Jul 2006 11:37:57 -0400 User-Agent: KMail/1.9.1 References: <200607181317.33416.gmccaughan@synaptics-uk.com> <200607191336.54880.jhb@freebsd.org> <200607211507.02139.gmccaughan@synaptics-uk.com> In-Reply-To: <200607211507.02139.gmccaughan@synaptics-uk.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-6" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200607211137.58230.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [192.168.0.1]); Fri, 21 Jul 2006 12:04:10 -0400 (EDT) X-Virus-Scanned: ClamAV 0.87.1/1612/Thu Jul 20 15:41:45 2006 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on server.baldwin.cx Cc: freebsd-hackers@freebsd.org Subject: Re: "swiN: clock sio" process taking 75% CPU X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jul 2006 16:04:17 -0000 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