Received: by 2002:a05:6a10:8c0a:0:0:0:0 with SMTP id go10csp2512951pxb; Mon, 18 Jan 2021 21:47:00 -0800 (PST) X-Google-Smtp-Source: ABdhPJxeJ4vvgO6j+nFXO9q3B6FpE/xjh+4gwETKvyoQ1GM1oqxhLwAmUOw2CKm4kUQ6Npqg88sc X-Received: by 2002:a17:906:94d2:: with SMTP id d18mr1935461ejy.94.1611035220043; Mon, 18 Jan 2021 21:47:00 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1611035220; cv=none; d=google.com; s=arc-20160816; b=rT/6KoQf3LvELBEy09vNguTvHT5ObwB7X9bY9mUHMW/FIvEp/PnhfxollxoZZ/7nbY VFwGRZLoolAAS9Fjz97+NNGepoVnxySlBQh8An9+7n6r97cbokPglaAoUWaYFCv44NZE S9R4lMG5NzrK210P8KsvOy9PZ7LxusXSuI5u3t3yiC1KWJP2buLfhufTY3se7KGO/MX7 K8yFvNtgB84yM9w9j/jy3KRbT+ls1RfZVsJQOCc3JK1suEwKpZ0Rk0g7bUWPud7FGiel 9ZAv3f/5t/so+V6WggFdXiRDk45tG0ylRH0RQQrhr8bGEt/ZE3jdC9MEkO4zL4zSQEKB RVGQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:ironport-sdr :ironport-sdr; bh=zzfNIUmjwl5plPvNDezllYAIupogi46dP4bZLQULVyE=; b=NdtfPVOaTGZaX0rsni6a0QsJUmB5eznrBeEEKISAWKK7OvNpjb/znealVY/EjLE9gW 8Uyh8gLrRO63XtEzaqFg7oXDs/X7vR+IbIZ2CBXE5F1CHe6sPSvMde5lxcLzeePTBuhR 2hkIDXzmLdvDpGyKrE3Mc0C3VFM5P+Ua77rcTWDKnMZ+UPMU0TGoOjXvh80NetS4oC9G gfDfHt1SQPs+np+57dCh1z8obWi+ukM6HiM2RLsPT3oosmlyxZJlmXGFFfm5Ly95SzO5 Y/mf7r+8de1GYDf1yXwJrDo3/b9nxL+P079amknR0+vY0XyfqYV7OOdaWfH3/pR+rlNP g7Mw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id l14si3805491edw.437.2021.01.18.21.46.36; Mon, 18 Jan 2021 21:47:00 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2394355AbhASCs4 (ORCPT + 99 others); Mon, 18 Jan 2021 21:48:56 -0500 Received: from mga01.intel.com ([192.55.52.88]:17797 "EHLO mga01.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728372AbhASCsv (ORCPT ); Mon, 18 Jan 2021 21:48:51 -0500 IronPort-SDR: rVTY+pv7nd30aUIYwRCzPlO/ZQAPXrf+qqOU6kX7E3NG2pBPnP5Qs+VnfTOiNj3n/GEOqLQu1I HJBfTU9nIv4A== X-IronPort-AV: E=McAfee;i="6000,8403,9868"; a="197571123" X-IronPort-AV: E=Sophos;i="5.79,357,1602572400"; d="scan'208";a="197571123" Received: from orsmga008.jf.intel.com ([10.7.209.65]) by fmsmga101.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 18 Jan 2021 18:47:05 -0800 IronPort-SDR: QbnPoavpYIEOL8Av9ZMrn59/UhQXh2rRMRqLb2IBAjyvpfQFSi4BpC4csLZu6aEpGeBOpaLqeb Zcj+CrSEwDVw== X-IronPort-AV: E=Sophos;i="5.79,357,1602572400"; d="scan'208";a="383763560" Received: from tassilo.jf.intel.com ([10.54.74.11]) by orsmga008-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 18 Jan 2021 18:47:04 -0800 Date: Mon, 18 Jan 2021 18:46:57 -0800 From: Andi Kleen To: Namhyung Kim Cc: Peter Zijlstra , Arnaldo Carvalho de Melo , Jiri Olsa , Ingo Molnar , Mark Rutland , Alexander Shishkin , LKML , Stephane Eranian , Ian Rogers , Alexey Alexandrov Subject: Re: [PATCH] perf/core: Emit PERF_RECORD_LOST for pinned events Message-ID: <20210119024657.GA3526@tassilo.jf.intel.com> References: <20210118034323.427029-1-namhyung@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org > > I don't think I object to having an even in the stream, but your LOST > > event is unfortunate in that it itself can get lost when there's no > > space in the buffer (which arguably is unlikely, but still). > > > > So from that point of view, I think overloading LOST is not so very nice > > for this. > > But anything can get lost in case of no space. > Do you want to use something other than the LOST event? Could always reserve the last entry in the ring buffer for a LOST event, that would guarantee you can always get one out. -Andi