Received: by 10.213.65.68 with SMTP id h4csp1471549imn; Wed, 14 Mar 2018 23:58:13 -0700 (PDT) X-Google-Smtp-Source: AG47ELuZh/bOOVfi+MmqIDP1zFWQi59X13JlsJpEBkEflpbNcG5uUUr9PYSH48Vw4qV78bkIHLsV X-Received: by 10.98.10.65 with SMTP id s62mr6742420pfi.234.1521097093757; Wed, 14 Mar 2018 23:58:13 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1521097093; cv=none; d=google.com; s=arc-20160816; b=yRyu2PBrPqq3eXS1AaeRw4cMV/vgzOfzpL8202kfgyrDKeT0CYkebv8XSGxTQgKRY2 OcsGpqChuxWb7XCuSWaN6g1NoLaQ0FVNRmp84SpPlU0RCR/t2RydiYvOF2NmMyj5vK5W 6Exmzy2ib3cTP/O8j625hxTISGMXkFt1G/ihNjBTr4vrvSne6Lklv0Q2Onov0ZkYiR5v 5feLTB80m9Kniwh1GDpZyw4EJtqV9Av3oGWfqkEN9SO9sB3m5Ov9H3v5LgsvSwCc6PUm R6z8cQEzMuSxkqeRIY7zMQsNX9TB2J3NP/DUyLz6v4NvhJaX+RKn+69NsDPVe1FNTlkr kTYw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :references:in-reply-to:mime-version:arc-authentication-results; bh=SO4L1LA3bQCXuVm07OqInALQlw7XEkrpWb4Bp0/+OWo=; b=Dq4lEWB7An/D3iYE36pWvRakYYvLQ+XqVUVVUgbCqraQg4tK4VTghFjkod4gGyVvWy IjXLhQruiuEP1ip93dcuW09ox8YtLWeHWOnYiFW5A5W86SYV14X/oMEgmOs+Bs/0uesl tQMViFH/ITwybq0eSVQDhmal4HQajA9rfefdcAkiMeVcPGDvwm7liOYmIDo5jsFK/jYQ uNVau+zt5H/sYFnMh9uXgaT6gxdtgPJ0h/PjDLHM9/Gc2kpKvJ8RLJWczGQIg42ldp8k VAUVsYf9m26mJFt8ucja9CfsGKK+iy7YsnJHNRbA1v5GAlHFCdQz6gwbddW06X0LnyNQ +w0g== 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id s3-v6si425503plp.128.2018.03.14.23.57.59; Wed, 14 Mar 2018 23:58:13 -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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751410AbeCOG5H (ORCPT + 99 others); Thu, 15 Mar 2018 02:57:07 -0400 Received: from mail-ot0-f169.google.com ([74.125.82.169]:46276 "EHLO mail-ot0-f169.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750715AbeCOG5G (ORCPT ); Thu, 15 Mar 2018 02:57:06 -0400 Received: by mail-ot0-f169.google.com with SMTP id g97-v6so5823880otg.13 for ; Wed, 14 Mar 2018 23:57:06 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=SO4L1LA3bQCXuVm07OqInALQlw7XEkrpWb4Bp0/+OWo=; b=CeTsmXg0BmogpBtvu2yxWBOEnTHBy/eSnj4r3ouXhDwRBco+oIS9X4quhV9MT4+1xP xVcf3sKSoTbLx+u5KqEZfdZn41Ygsuo+OVPLWRYDB0SeArlyX1BJj81faIcfD1231I+e FcHGCqlfiIBRq2w/0KTxLbwM+XpOVTCNgcIDim1An9/H7wCgWP8UdfqfRjrtG1CsDH+9 2tgHxf7FaDFKamLxRCOLFJdibLW286y1dwXNxkRbLO5lXIU0AmhScZGBji7o1f/IVYeR JbCGpehZDh/SVb6VbsJo3kRTFvkTBZvqH81B4I3Uwigz2NtziRiXAymWCy/Jtdgsy9Yo 27qA== X-Gm-Message-State: AElRT7FbSIjT+fM9SupABKN+kTckmDmWRVdGLUAsG/UE0rDmmyRQwCEB DYJUjPMgUIQMnzS2m7BL6QUjOfZqbFEy65hospH7ow== X-Received: by 10.157.68.57 with SMTP id u54mr4485470ote.67.1521097025977; Wed, 14 Mar 2018 23:57:05 -0700 (PDT) MIME-Version: 1.0 Received: by 10.74.31.134 with HTTP; Wed, 14 Mar 2018 23:57:05 -0700 (PDT) In-Reply-To: <20180314211704-mutt-send-email-mst@kernel.org> References: <20180301142215.11812-1-idgar@virtualoco.com> <20180313190617-mutt-send-email-mst@kernel.org> <20180314182536.GA14504@kroah.com> <20180314211704-mutt-send-email-mst@kernel.org> From: Gal Hammer Date: Thu, 15 Mar 2018 08:57:05 +0200 Message-ID: Subject: Re: [PATCH v5] drivers/misc: vm_gen_counter: initial driver implementation To: "Michael S. Tsirkin" Cc: Greg KH , Or Idgar , linux-kernel@vger.kernel.org, Arnd Bergmann , Or Idgar , Or Idgar Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Mar 14, 2018 at 9:25 PM, Michael S. Tsirkin wrote: > On Wed, Mar 14, 2018 at 07:25:36PM +0100, Greg KH wrote: >> On Tue, Mar 13, 2018 at 07:40:51PM +0200, Michael S. Tsirkin wrote: >> > I think it's a good idea to use sysfs for this. However, >> > there are a couple of missing interfaces here: >> > >> > 1. Userspace needs a way to know when this value changes. >> > I see no change notifications here and that does not seem right. >> >> How can these change? > > It's a hardware register. It changes when hardware feels like it :) > In particular, it changes whenever VM is migrated or snapshotted. This value doesn't change when a VM is migrated. It is unlikely that this value will be changed so frequently that a direct access to the memory is required. Even in QEMU, the current implementation was merged without an option to change the generation id on-the-fly. One must run a new instance in order to set a new value, which means that no application will be running during that time. >> > 2. Userspace needs to be able to read these without >> > system calls. >> >> Ick, what? Why not? >> >> > Pls add mmap support to the raw format. >> >> For a single integer? Why do you need mmap for this? What is so >> "performant" that needs to touch a sysfs file? >> > (Phys address is not guaranteed to be page-aligned so you will >> > probably want an offset attribute for that as well). >> >> Ick ick ick, that's why it's good to just stick with a sysfs file. I agree with Greg here. The user is able to read the value, and then wait for a notification if she cares about changes. >> Have you tested just how long this takes to see if the open/read/close >> is really the bottleneck, or if the io on reading the value is the >> bottleneck? >> >> thanks, >> >> greg k-h > > Well an application needs to check this value basically after > every database transaction. So I'm pretty sure it's a performance > sensitive path. But yes, I didn't profile any apps since they > are yet to be written to use this interface. > I'm fine deferring point 2 for now. > > -- > MST Thanks, Gal.