From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [Qemu-devel] Re: [PATCH 0/4] Rework alarm timer infrastrucure - take2 Date: Sun, 19 Aug 2007 16:48:06 +0300 Message-ID: <46C84A16.7040305@qumranet.com> References: <20070817231149.544849769@gmail.com> <1187450256.13580.1.camel@squirrel> <64F9B87B6B770947A9F8391472E032160D4645F0@ehost011-8.exch011.intermedia.net> <20070818220252.GA19526@dreamland.darkstar.lan> <1187481505.15472.3.camel@squirrel> <46C7FE32.4050309@qumranet.com> <20070819131042.GA22798@mail.shareable.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Cc: kvm-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org, qemu-devel-qX2TKyscuCcdnm+yROfE0A@public.gmane.org To: Jamie Lokier Return-path: In-Reply-To: <20070819131042.GA22798-tp2ajI7sM85Y6zH9YvfY1x2eb7JE58TQ@public.gmane.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kvm-devel-bounces-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org Errors-To: kvm-devel-bounces-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org List-Id: kvm.vger.kernel.org Jamie Lokier wrote: > Avi Kivity wrote: > >>>>> In this case the dyn-tick minimum res will be 1msec. I believe it should >>>>> work ok since this is the case without any dyn-tick. >>>>> >>>>> >>>> Actually minimum resolution depends on host HZ setting, but - yes - >>>> essentially you have the same behaviour of the "unix" timer, plus the >>>> overhead of reprogramming the timer. >>>> >>>> >>> Is this significant? At a high guest HZ, this is could be quite a lot >>> of additional syscalls right? >>> >>> >> At HZ=1000, this adds a small multiple of 1000 syscalls, which is a >> fairly small overhead. >> > > Small, but maybe measurable. > > That overhead could be removed if the dyn-tick code were to > predictively set the host timer into a repeating mode when guests do > actually require a regular tick. > > I'm thinking when it detects it needed a tick a small number of times > in a row, with the same interval, it could set the host timer to > trigger repeatedly at that interval. Then it wouldn't need to reprogram > if that stayed the same (except maybe to correct for drift?) > > If a tick then _wasn't_ required for that interval (i.e. it was > required for less, more, or not at all), then it would have to > reprogram the host timer. If it really mattered, it wouldn't have to > reprogram the host timer when the next required tick is further in the > future or not at all; it would simply be a redundant SIGALRM. In > weird cases that's worthwhile, but I suspect it generally isn't. > > Yes, good thinking, but this should only be done if it actually impacts something. Reducing overhead from 0.1% to 0.05% is not worthwhile if it introduces extra complexity. -- error compiling committee.c: too many arguments to function ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/