From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [PATCH 2/6] kvm-s390: use hrtimer for clock wakeup from idle Date: Thu, 07 May 2009 13:19:32 +0300 Message-ID: <4A02B5B4.6050701@redhat.com> References: <1241534358-32172-1-git-send-email-ehrhardt@linux.vnet.ibm.com> <1241534358-32172-3-git-send-email-ehrhardt@linux.vnet.ibm.com> <4A017E1F.6030908@redhat.com> <200905061436.13071.borntraeger@de.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: ehrhardt@linux.vnet.ibm.com, kvm@vger.kernel.org, Carsten Otte To: Christian Borntraeger Return-path: Received: from mx2.redhat.com ([66.187.237.31]:57978 "EHLO mx2.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1760244AbZEGKTg (ORCPT ); Thu, 7 May 2009 06:19:36 -0400 In-Reply-To: <200905061436.13071.borntraeger@de.ibm.com> Sender: kvm-owner@vger.kernel.org List-ID: Christian Borntraeger wrote: >> Why can't this be done from the timer context (after adjusting the locks)? >> > > It can be done, in fact I did that in my first version. The thing is, we would need to change all local_int.locks to spinlock_irqs, since standard timers are softirqs and hrtimers and hardirqs. Enabling and disabling irqs is a relatively expensive operating on s390 (but locks via compare and swap are quite cheap). Since we take this specific lock in lots of places this lock is on some hot pathes. The idle wakeup on the other hand is not that critical. > Makes sense. Back when irqsave/irqrestore were expensive on x86 (P4 days, I think it was ~100 cycles) there was talk of using a software irq disable flag instead of using the hardware support. So - local_irq_disable() sets a flag - interrupt handlers check the flag, if set they schedule the interrupt handler and return immediately - local_irq_restore() clears the flag and fires and scheduled handlers Now these operations are pretty cheap on x86, but maybe that can apply to s390. -- error compiling committee.c: too many arguments to function