Date: Tue, 10 Feb 2015 13:32:37 -0700 From: Ian Lepore <ian@freebsd.org> To: John-Mark Gurney <jmg@funkthat.com> Cc: Adrian Chadd <adrian@freebsd.org>, "src-committers@freebsd.org" <src-committers@freebsd.org>, Rui Paulo <rpaulo@freebsd.org>, John Baldwin <jhb@freebsd.org>, "svn-src-all@freebsd.org" <svn-src-all@freebsd.org>, "svn-src-head@freebsd.org" <svn-src-head@freebsd.org> Subject: Re: svn commit: r278479 - in head: etc sys/kern Message-ID: <1423600357.80968.25.camel@freebsd.org> In-Reply-To: <20150210201550.GH1953@funkthat.com> References: <201502092313.t19NDpoS083043@svn.freebsd.org> <1516483.e0EXgdk9ur@ralph.baldwin.cx> <CAJ-Vmomm=vZtaYRXjo-Oyw0cAjYaa1dQHLPPGc4KT6txTuQzRw@mail.gmail.com> <2907775.GXqUUp6Hz6@ralph.baldwin.cx> <20150210201550.GH1953@funkthat.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1423600357.80968.25.camel>