Date: Sun, 7 Apr 1996 13:00:57 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: roell@blah.a.isar.de (Thomas Roell) Cc: msmith@atrad.adelaide.edu.au, roell@blah.a.isar.de, terry@lambert.org, hackers@FreeBSD.ORG, jkh@time.cdrom.com, roell@xinside.com Subject: Re: The F_SETOWN problem.. Message-ID: <199604072000.NAA00425@phaeton.artisoft.com> In-Reply-To: <199604071839.UAA00701@blah.a.isar.de> from "Thomas Roell" at Apr 7, 96 08:39:34 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> Dongle ... good idea. I have to ask our marketing about that ! Oh yes, the only thing preventing me from buying it now is an attractive dongle (note: if you are marketing geek, you may not have recognized this as sarcasm. It is sarcasm.). > > > The other reasons is more tricky. We do have reports from people that > > > under heavy load they loose sync of the PS/2 mouse. The PS/2 mouse is > > > > I must say I'm not entirely sure that signal delivery will help lots > > here; certainly it would get your reads happening as soon as the > > server ran again. > > Well I guess there is a long explanation necessary. First off it > should be obvious why SIGIO solves any possible problem, since the > signal-handler can process the input directly, and even if it just > means to buffer it in a larger buffer. Now a X-Server does some really > tricky things to lower the cost of a dispatch cycle. Basically > input-devices are ONLY polled after a select() system call. However > one gets only back to the select system call if there is no more data > left from the previous select() call, which means a client that > overruns the X-Server with data can basically lock out any io. And if > this happens long enough, the kernel-device buffer will overflow. Ah. It seems you are doing your I/O processing by doing a read for some huge amount with the possibility of returning less than the requested amount. Then processing multiple runs of data in a loop instead of going back up to the top of the loop. Programatically, this is bad... it's like expecting XNextEvent() to not buffer multiple inputs for a single select true, and using a select in the main loop instead of checking XPending(). The fix for this is to virtualize the "data available" state bits for each fd, and for buffered data, not set the bit on the select if there is more data pending. Then when the select comes true, you OR in the select return bits to the current virtual bits to get the new virtual bits. That way, you still go through the motions of going to the select each time through the loop in your finite state automaton, and you can put examination of the mouse fd virtual bit at the front of the loop. The remaining problem is to set a null-valued timeval struct if any virtual bits are set at the time of entry so the select will not block if no data is available on the virtualized fd's that are currently not set (ie: virtual data available is true but real data avilable is false). I could understand wanting to use a signal handler if your problem was it taking long enough to overflow the buffer to complete a single state transition in the automaton; after all, signals get processed on any system call exit from the kernel, not just select(). But your problem is that the automaton is not running at sufficient granularity to generate a real-time response (which is why using the pipe() call and selecting on the slave end and writing messages to yourself that way won't cut it as a fix). Is there some reason you can't just increase the buffer in the kernel to prevent an overflow, if you insist on long delay state processing of many events without going back out to the top level of the I/O automaton? > > > different from all other mice, as there is now way to figure out from > > > the byte-stream when a 3 byte packet starts. There is supposed to be a > > > sync-bit, but half of the PS/2 mice do not set it. The PS/2 kernel > > > > Ah, I've been here before 8) If you can at all, use an idle timeout. > > If you have no mouse traffic for a second (or two or three), reset > > your state machine. I'm aware that this won't help the heavy traffic > > sync loss that you'll get if the buffer's overrun, but it will get > > you back in sync if you leave the mouse alone. > > (apologies if I'm trying to teach you to suck eggs 8) > > We are doing exactly this already. But still the effect is quite > noticable for certain applications. The customer really didn't like my > comment about his broken hardware ;-) The fix here is to virtualize all mouse I/O in the kernel instead of presenting seperate abstractions that the X server has to deal with. That way, even if you are dumping data on an overflow, you can do so only on boundries (or you can dynamically start suckung up buffer space to not lose data at all). One problem (from a casual glance at the driver) seems to be that you would want to prioritize button events ahead of motion events -- use a split LRU queue and throw away old consecutive motion events without an intervening button event to favor button events. Really, a buffer overflow is telling you one of two things: a) Your event buffer is too small b) You are taking too long in your atomaton before getting back to the state where the buffered events can be processed, and you need to fix the automaton. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199604072000.NAA00425>