From mboxrd@z Thu Jan 1 00:00:00 1970 From: Keir Fraser Subject: Re: [PATCH 0/2] range timer support Date: Tue, 28 Oct 2008 15:37:09 +0000 Message-ID: References: <631d03500810280815y3a415fb2n358f1ebd74111571@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <631d03500810280815y3a415fb2n358f1ebd74111571@mail.gmail.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Yu Ke Cc: "Liu, Jinsong" , "Tian, Kevin" , "xen-devel@lists.xensource.com" , "Wei, Gang" , "Yu, Ke" List-Id: xen-devel@lists.xenproject.org On 28/10/08 15:15, "Yu Ke" wrote: > and IMHO, the power consumption and inaccuracy trade-off is not a > central policy, each user know better about its tolerance, so it may > be better to let user to decide. Yes, I can see there is a fundamental difference in points of view here. I would point out that, in your second patch, it's not clear there's any particular reason for the constants chosen in: MIN(pt->period/8, MILLISECS(1)) How did you arrive at this formula? Why 1ms rather than 2ms, 10ms, or 500us? Why 8 rather than 16 or 4? Ultimately the entity that really knows what bounds are reasonable on sloppiness of a guest timer device would be the guest itself: the kernel, or applications running on it, or users interacting with that guest software. Otherwise I think you're making a somewhat uninformed tradeoff between performance and power. And in that case, if the balance point doesn't need to be chosen all that accurately, then centralising and hiding the sloppiness seems a good idea to me. Also that allows the potential for easier central tunability: do you want performance more than power, or vice versa? -- Keir