svn commit: r278479 - in head: etc sys/kern

Ian Lepore ian at freebsd.org
Tue Feb 10 22:23:39 UTC 2015


On Tue, 2015-02-10 at 12:15 -0800, John-Mark Gurney wrote:
> John Baldwin wrote this message on Tue, Feb 10, 2015 at 10:36 -0500:
> > > I think devd grows these things because it's easier than teaching the
> > > devctl interface to support multiple listeners.
> > 
> > That wasn't really my question.  My question was if we want distinct streams 
> > or if we want want unified stream.  Having a unified stream might very well 
> > make sense (and if so we could rename devd to make that more obvious).
> 
> The biggested issue that I see w/ using devd as the gateway is that
> as we add more events, devd will now have to be woken up for ALL events,
> even when the even has no listeners for it...  If we keep adding events,
> this will be very bad for laptop battery life...
> 

That's similar to my worry but for our apps at $work the problem extends
to them as well... the kernel will wake up devd for lots of events it
doesn't need to process, then it fans them out to our app which also
gets woken for events that it's not interested in.  Big iron in
datacenters isn't going to have any problems with this, but embedded
systems at the low end are still somewhat cycle-sensitive.

The worrisome part is the creep.  Right now it's just crashdumps, and
that isn't going to add any overhead for $work, because our apps never
crash (::grin::).  But the floodgates are open and in a couple years
it's going to be a lot of new kinds of events and a lot of new cycles
consumed processing them in userland.

> This is becoming a standard pub/sub type problem, and there is plenty
> of research/programs out there that already does this...
> 
> As someone mentioned earlier, it seems like using kqueue is starting
> to make more sense for this type of thing where various programs can
> select what they get woken up for...
> 

Filtering at the source (or nearer to it) does seem to be one way to get
everything that's good about a generic event notification daemon without
all of the bad that will accumulate if we just stumble into it without a
long term vision.  I'm not as familiar with kevent specifics as I'd like
to be, so I can't say it's a ready to use off the shelf solution, but it
may be part of one.

-- Ian




More information about the svn-src-head mailing list