From owner-svn-src-all@FreeBSD.ORG Tue Feb 10 18:51:59 2015 Return-Path: Delivered-To: svn-src-all@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C34A56D1; Tue, 10 Feb 2015 18:51:59 +0000 (UTC) Received: from zxy.spb.ru (zxy.spb.ru [195.70.199.98]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 79AA374E; Tue, 10 Feb 2015 18:51:59 +0000 (UTC) Received: from slw by zxy.spb.ru with local (Exim 4.84 (FreeBSD)) (envelope-from ) id 1YLFub-000Lcl-9U; Tue, 10 Feb 2015 21:51:53 +0300 Date: Tue, 10 Feb 2015 21:51:53 +0300 From: Slawa Olhovchenkov To: Rui Paulo Subject: Re: svn commit: r278479 - in head: etc sys/kern Message-ID: <20150210185153.GA81421@zxy.spb.ru> References: <8e5503e1-755c-49e4-ab4d-a0ad1ae91f97@me.com> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <8e5503e1-755c-49e4-ab4d-a0ad1ae91f97@me.com> User-Agent: Mutt/1.5.23 (2014-03-12) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: slw@zxy.spb.ru X-SA-Exim-Scanned: No (on zxy.spb.ru); SAEximRunCond expanded to false Cc: "svn-src-head@freebsd.org" , Adrian Chadd , "src-committers@freebsd.org" , "svn-src-all@freebsd.org" , John Baldwin X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Feb 2015 18:51:59 -0000 On Tue, Feb 10, 2015 at 06:30:27PM +0000, Rui Paulo wrote: > On Feb 10, 2015, at 07:37 AM, John Baldwin wrote: > 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). > > I'm fine with renaming devd to eventd or something else, but Ian was > saying that he's worried about the number of notifications that devd > has to process. šI'm not sure that's a real problem at this point, > though. šOn freefall, devd used 0.07 seconds of CPU time and has > been running for a 1 day and a half. šOn my BeagleBone, devd used > 0.61 seconds of CPU time and it has been up for 5 days and a half. š > On my VM that has been up for 5 days and a half, it used 4 seconds > of CPU time. šRenaming sounds like a good idea and it looks like we > could leave the optimisations to a later time. For common case (I am not talk about current devd implementation -- I am don't have any inforamtion/metrics/etc) routing and processing events may be sensitive to delay and ordering: may be exist requirement 'delay not more then 700ns', may be exist requirement 'next event process only after complete process previos event'. And some event handling may be very CPU/disk/etc consumption. Need to good think over and design API and architecure.