On Wed, Feb 17, 2016 at 4:52 PM, Taylor R Campbell <campbell+netbsd-source-change...@mumble.net> wrote: > Date: Wed, 17 Feb 2016 15:12:31 +0900 > From: Ryota Ozaki <ozak...@netbsd.org> > > On Wed, Feb 17, 2016 at 2:13 PM, Taylor R Campbell > <campbell+netbsd-source-change...@mumble.net> wrote: > > Note that this queueing takes effect only if the link state changes > > multiple times within maybe a few microseconds, before the softint can > > run. If your link state is changing that many times so quickly, > > losing an event or two is probably the least of your worries > > Yeah, it's nitpicking, but for that reason, I think it's better to pass > events as they are to userland. > > > -- but > > you're probably more interested in seeing something like ...down...up > > than ...up/up/up. > > Yes. (up/up/up events are eliminated in the first place though.) > > So what events would you choose to skip, if not the scheme that Roy > described?
(I think I confused you, sorry...) I rather want to not skip anything as much as possible (except for repeating same events (e.g., up/up/up) because keeping them all changes the original behavior). I intend to skip/eliminate events only if there are too many events happen in a short period (i.e., need queuing) to protect the system from overloading. In that case (it's a very rare case I think), we just drop an earliest event first. > > I bet that, whatever events you would choose to skip, we can still > prove that the resulting queues need be no longer than, say, three > elements, and we'd still usefully report link flapping to userland -- > as long as we can make enough progress to run softints and userland > processes at all. > > Here are some example reductions that intuitively sound reasonable to > me: > > down/down = down > up/up = up > down/unknown/up = down/up > down/up/down = down > > What other sequences of events would you simplify? As I said, I want to keep the sequences (except for repeating same events) so the last two examples will be sent as they are. ozaki-r
