Date: Sat, 17 Dec 2011 16:57:30 +0200 From: Andriy Gapon <avg@FreeBSD.org> To: Hans Petter Selasky <hselasky@c2i.net> Cc: usb@FreeBSD.org, freebsd-hackers@FreeBSD.org, John Baldwin <jhb@FreeBSD.org>, mdf@FreeBSD.org Subject: Re: kern_yield vs ukbd_yield Message-ID: <4EECADDA.4070704@FreeBSD.org> In-Reply-To: <201112152356.35336.hselasky@c2i.net> References: <4EE51CB5.1060505@FreeBSD.org> <201112142256.32526.hselasky@c2i.net> <4EEA015D.8020800@FreeBSD.org> <201112152356.35336.hselasky@c2i.net>
next in thread | previous in thread | raw e-mail | index | archive | help
Replying further... on 16/12/2011 00:56 Hans Petter Selasky said the following: > On Thursday 15 December 2011 15:17:01 Andriy Gapon wrote: >> Hmm... I looked at the history of ukbd.c (which I should have done from the >> very start) and I see two relevant revisions: >> http://svnweb.freebsd.org/base/head/sys/dev/usb/input/ukbd.c?r1=199816&r2=2 >> 03896&pathrev=203896 >> http://svnweb.freebsd.org/base/head/sys/dev/usb/input/ukbd.c?r1=223755&r2= >> 223989&pathrev=223989 >> >> So, first use of pause(9) was introduced to work around current broken >> syscons polling mechanism. Then pause(9) was replaced with the >> hand-rolled yield to fix a problem at shutdown, which supposedly was >> caused by times being stopped. >> >> None of the commits seems to be directly related to thread priorities. > > Not directly, but indirect. You know, if you pause thread 1 (which I thought > was thread 0), then other thread will get a chance to run. pause() could be a sufficient action to let other thread run, but it is not a required action. As we've already discusses earlier all the USB threads have sufficiently high priorities to get runnable while other kernel threads are runnable. Only certain interrupt threads could have prevented them from running, but that's definitely not the case. > It might also be that Giant is locked by syscons, and that unless you pause or > yield, then Giant will block other parts of USB, like the callback thread, > which is Giant locked for ukbd only to run. > > Maybe that is the explanation? Not sure if you are hypothesizing or if this is something that you experienced during development and testing. Let's consider a few observations. First, syscons doesn't acquire Giant anywhere in the path started from cngetc. Actually, I believe that the only place where Giant is now explicitly acquired in the whole syscons code can be safely replaced with an assert that the Giant is already held. Second, the polling mode is designed to be usable in situations where other threads are not running. So in general it should not depend on other threads being able to make any progress. -- Andriy Gapon
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4EECADDA.4070704>