From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S966730AbbBDPXE (ORCPT ); Wed, 4 Feb 2015 10:23:04 -0500 Received: from mail9.hitachi.co.jp ([133.145.228.44]:51845 "EHLO mail9.hitachi.co.jp" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S966580AbbBDPWx (ORCPT ); Wed, 4 Feb 2015 10:22:53 -0500 Message-ID: <54D23946.6000106@hitachi.com> Date: Thu, 05 Feb 2015 00:22:46 +0900 From: Masami Hiramatsu Organization: Hitachi, Ltd., Japan User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: Arnaldo Carvalho de Melo , namhyung@kernel.org, Peter Zijlstra , Paul Mackerras , Ingo Molnar Cc: linux-kernel Subject: Perf buildid-cache gives a confusing message Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi, (Sorry, I missed CC to LKML) I've found a bit odd perf-buildid-cache behavior. It seems to be as designed, but also a bit confusing. Issue: perf-buildid-cache's --update and --remove operations refer the current existing binary at given path. This means if we update the old binary, it couldn't remove nor update the buildid-cache. Here is the example, ---- [mhiramat@localhost perf]$ ./perf buildid-cache -v --add ./perf Adding 51d0731187917e27fd733f2f6f34777cddbaec0f ./perf: Ok <-- (*) [mhiramat@localhost perf]$ rm perf [mhiramat@localhost perf]$ make clean [mhiramat@localhost perf]$ make [mhiramat@localhost perf]$ ./perf buildid-cache -v --update ./perf Updating 45a97daa65f9c58adeb34af4158a6dde747de49b ./perf: FAIL <-- (*) ./perf wasn't in the cache [mhiramat@localhost perf]$ ./perf buildid-cache -v --remove ./perf Removing 45a97daa65f9c58adeb34af4158a6dde747de49b ./perf: FAIL <-- (*) ./perf wasn't in the cache ---- Both --update and --remove are failed after updating local binary. Note that (*) are verbose message, without -v we don't see that. I know this is the designed behavior, buildid-cache manages binaries based on its build-id, not its path. However, it seems confusing. So, I'd like to suggest to fix --update FILE to add new binary to cache when there is no current binary cache (this will fix the first FAIL), and add --remove-all FILE to remove all existing buildid cache about FILE (path-based cleanup). What would you think about that? Thank you, -- Masami HIRAMATSU Software Platform Research Dept. Linux Technology Research Center Hitachi, Ltd., Yokohama Research Laboratory E-mail: masami.hiramatsu.pt@hitachi.com