Received: by 2002:a25:4158:0:0:0:0:0 with SMTP id o85csp2019919yba; Mon, 15 Apr 2019 03:19:03 -0700 (PDT) X-Google-Smtp-Source: APXvYqy/RrVWzZFyTsmzGT5dtIrztw5IsbOOr7xQJMqAic7EaPcAMzSbWV8TdLW1bvIRxL4rerdk X-Received: by 2002:a17:902:3e5:: with SMTP id d92mr71074908pld.11.1555323543639; Mon, 15 Apr 2019 03:19:03 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1555323543; cv=none; d=google.com; s=arc-20160816; b=olLzA8Mr3iltOljA3kn0SV6KPvhkP/YyWp/m0mygZPeFUSMDlXRhaIbS3MDCzY5a7i MBHxfofHIWzpNvTLchgkoOIKiDecej6JvX8Nhv23CtyoTIJg+nUZ3Lrgc8VQGyUKA72v RRIFLy+EPMRtz19ZZ5tuSEtszTgDXUhbB4yYgD5Ef2mPNmD9IcNGGZkN+71PdFr394FV ms9jsedVlXsllaU52raAGm6bmMhNOZrguBlQkcSCg8SJ8C1OIGC60EE8m7sRHrHINsnG PfPQh3O8mwxWpKaydRCuE/X6elOZGWnIl1sYnKXTapwTSUjlvNACPbx1qFzhj0UrIWRr NVNA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject; bh=SG8aXbL+ml3wh44VZyBOzACDTctAGgpmKm/WfSQF2xI=; b=eSynGAhA++Rnp6OYWVQWqHBqUQShPugsdVR9Oz5S7lvzN/pNZDc5GUX/X+fnMfNcqE +v7S2GBepzEGpgiB6asCuZrjjN4lzec5zoghG9Q2jhLqg4/3p6NarV1CG9kMlP/CNLPF 0meYeN9ROGAby1u6X8x/2YDUdVel8LC0rO20DrZRnEo+1CKjArBrzJkCltWQpaT+EgON e3uYkacS9D5LYo7C+psjlF68rcuGMeYzOlXwU8YaQ9l4C7Y6/ZL8R4KYxnCjIsCZkx59 HNcruwLXRjwvc8unLIGyfEjfzACr4FpD1CclQ4M2HtJw6vMBFNzRSnlzgQaBdRIIZ2pH ShYg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id w23si43344514plk.109.2019.04.15.03.18.47; Mon, 15 Apr 2019 03:19:03 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727184AbfDOKQA (ORCPT + 99 others); Mon, 15 Apr 2019 06:16:00 -0400 Received: from usa-sjc-mx-foss1.foss.arm.com ([217.140.101.70]:60016 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725939AbfDOKP7 (ORCPT ); Mon, 15 Apr 2019 06:15:59 -0400 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 3356180D; Mon, 15 Apr 2019 03:15:59 -0700 (PDT) Received: from [10.1.196.72] (e119884-lin.cambridge.arm.com [10.1.196.72]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 69AA03F557; Mon, 15 Apr 2019 03:15:58 -0700 (PDT) Subject: Re: [PATCH 2/3] x86/vdso: Allow clock specific mult and shift values To: Thomas Gleixner , Huw Davies Cc: linux kernel , Andy Lutomirski References: <20190411101205.10006-1-huw@codeweavers.com> <20190411101205.10006-3-huw@codeweavers.com> <20190415093042.GA21726@merlot.physics.ox.ac.uk> From: Vincenzo Frascino Message-ID: <82a61daf-f6f9-8be0-2157-e9f9d7ba1cdf@arm.com> Date: Mon, 15 Apr 2019 11:15:56 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Thomas, On 15/04/2019 10:51, Thomas Gleixner wrote: > On Mon, 15 Apr 2019, Huw Davies wrote: > >> On Sun, Apr 14, 2019 at 12:53:32PM +0200, Thomas Gleixner wrote: >>> So it stays in the same cache line, but as we move the VDSO to generic >>> code, the mask field needs to stay and this will make basetime[CLOCK_MONOTONIC] >>> overlap into the next cache line. >> >> Thanks for the great review; this is a good point. >> >>> See https://lkml.kernel.org/r/alpine.DEB.2.21.1902231727060.1666@nanos.tec.linutronix.de >>> for an alternate solution to this problem, which avoids this and just gives >>> CLOCK_MONOTONIC_RAW a separate storage space alltogether. >> >> I can certainly do this for the x86 vdso. Would that be useful or >> should I wait for Vincenzo's work on the generic vdso first? > > Depends. If Vincenzo comes along with his new version soon, then you might > get this for free :) > > Vincenzo, what's the state of your work? > I am mostly done with the development, the only thing missing is the integration of the generic update_vsyscall. After this is complete, I will need to do some testing and extract the performance numbers. Considering that I will be on Easter holiday from this Wednesday till the end of April, I think v6 will be ready around second week of May. > Thanks, > > tglx > -- Regards, Vincenzo