From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933297AbcFISJN (ORCPT ); Thu, 9 Jun 2016 14:09:13 -0400 Received: from mail-oi0-f49.google.com ([209.85.218.49]:35354 "EHLO mail-oi0-f49.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933056AbcFISJF (ORCPT ); Thu, 9 Jun 2016 14:09:05 -0400 MIME-Version: 1.0 In-Reply-To: <3bfffd0d-bb91-d9e3-b67b-a82be9cb82d7@redhat.com> References: <1465471403-49372-1-git-send-email-pbonzini@redhat.com> <20160609124317.GC2570@rkaganb.sw.ru> <20160609133529.GA5400@rkaganb.sw.ru> <8c422861-ab1e-ccdc-70e4-8517416e93f4@redhat.com> <3bfffd0d-bb91-d9e3-b67b-a82be9cb82d7@redhat.com> From: Andy Lutomirski Date: Thu, 9 Jun 2016 11:08:44 -0700 Message-ID: Subject: Re: [PATCH] pvclock: introduce seqcount-like API To: Paolo Bonzini Cc: Roman Kagan , "linux-kernel@vger.kernel.org" , kvm list , Minfei Huang , Andrew Lutomirski Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Jun 9, 2016 at 11:03 AM, Paolo Bonzini wrote: > > > On 09/06/2016 19:12, Andy Lutomirski wrote: >> On Thu, Jun 9, 2016 at 6:45 AM, Paolo Bonzini wrote: >>> On 09/06/2016 15:35, Roman Kagan wrote: >>>> On Thu, Jun 09, 2016 at 02:47:54PM +0200, Paolo Bonzini wrote: >>>>> On 09/06/2016 14:43, Roman Kagan wrote: >>>> Has it landed in any public tree? I'm unable to find any. There >>>> appears to be another version of the patch on the list, so I'm confused. >>> >>> I'm about to push it to kvm/master. >> >> Sorry for being slow. I'm catching up. In its current form, I don't >> like this patch. Please don't apply it. > > Sure, I was talking about Minfei's patches, not this one. :) Of course > I need ack for this one. > >> The problem is that this makes two significant changes at once: >> >> 1. Use the new version helpers. I like that change. >> >> 2. Use __pvclock_read_cycles. That should be separate, and it should >> come with timing numbers in the changelog. > > __pvclock_read_cycles is pretty much the same as the code that is being > inlined. Thus the only change is that __pvclock_read_cycles is called > inside the loop rather than outside, but the loop really is expected to > never roll so why make a copy in the first place? I feel like I had a reason, but I don't remember what it was. --Andy