Date: Mon, 16 Sep 2002 15:47:36 -0400 (EDT) From: John Baldwin <jhb@FreeBSD.org> To: Archie Cobbs <archie@dellroad.org> Cc: cvs-all@FreeBSD.org, cvs-committers@FreeBSD.org, "David O'Brien" <obrien@FreeBSD.org>, Josef Karthauser <joe@FreeBSD.org>, Bruce Evans <bde@zeta.org.au>, Poul-Henning Kamp <phk@critter.freebsd.dk> Subject: Re: cvs commit: src/sys/kern kern_timeout.c Message-ID: <XFMail.20020916154736.jhb@FreeBSD.org> In-Reply-To: <200209161903.g8GJ3e687116@arch20m.dellroad.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 16-Sep-2002 Archie Cobbs wrote: > Poul-Henning Kamp writes: >> >> > Sep 15 19:40:26 kernel: Expensive timeout(9) function: 0xc65dfc80(0xc659f000) 0.008711721 >> >> > Sep 15 19:40:26 kernel: Expensive timeout(9) function: 0xc65dfc80(0xc659f000) 0.001068850 >> > >> >This is hard to interpret without the function names (or a full stack >> >trace). >> >> Yes, but as far as I'm aware, we still don't have a print_backtrace(9) ? >> >> >I get these on an old dual Celeron system mainly for fxp_tick() >> >and uma_timeout(). >> >> uma_timeout() seems to trigger on practically all systems. >> I've talked with Jeff about it already. > > Would an option to timeout() like SPAWN_SEPARATE_THREAD be a practical > solution for some of these cases? I.e., optionally spawn a separate > thread to handle the timeout() event. > > This may be expensive, but there may also be some timeout events that > are rare, slow and expensive enough themselves to warrant using it. You can have a timeout handler that just does a wakeup of a worker thread. IWBN to include this type of functionality in the callout(9) API I suppose. -- John Baldwin <jhb@FreeBSD.org> <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?XFMail.20020916154736.jhb>