Received: by 2002:a05:6a10:1a4d:0:0:0:0 with SMTP id nk13csp1472731pxb; Wed, 2 Feb 2022 05:51:39 -0800 (PST) X-Google-Smtp-Source: ABdhPJx8y5gV2Wnh47Qf+0lY0czXlPWIqboJq/pteYW0T+4Tg5zZMQ+YW9z3mMtPgc/4hVKaonGx X-Received: by 2002:a63:26c1:: with SMTP id m184mr24965063pgm.296.1643809899265; Wed, 02 Feb 2022 05:51:39 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1643809899; cv=none; d=google.com; s=arc-20160816; b=AAMAaupaNzCWyEN19QziTh6sNWGazpNAZI624wSf4A55+WIIuiAI5S1dBqdRdUagDX jQJMyIgtDTK2i+MEn1K4b0tQaGdF52TWY6OlnHVVyJlIlG5zmnU0kCINS8EXHnaFlL9u jNj72PVWCn6e2vbEDRrylaWZMEx/bzVgXBAug2Kr30ru/XPSqO5UiEVzDNb1OQNk0FZZ 3dSufU+a6wlHkuPrAwZa+PBruLuboQVSLuBZKTguAYEEzWaOozVRahYPcJxSFGfltxb6 4MyDcM2FRpHQ34f1zEsl0btm8Mk4gaapWZxk/huu+IHRgBjKT4IixwB6RjEZ1jpTqYCf LtoA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:in-reply-to :organization:from:references:cc:to:content-language:subject :user-agent:mime-version:date:message-id:dkim-signature; bh=AjoBbHqv8iweA3y+yrLW4qUJUjtvLWobldjQ9zm27ME=; b=blCc5A+GSON+M4Dekbiqh1GRMJDDtHzvOHJ4YOznsNxLJd1XAoHrKVFkG1rRJu6VA4 0Dzz+doZU2lQo2SyDmBxJw59R9JgruX54OHxeD9jjFcyUNc7yZs36W4hASM0UA98INwU m3M9JUHsNAMMLGPvzWko6EJUWtScjlb9/rwL3HWWm/YBBZbQNLhN2TTIS3b/oeLvmMU7 dtEC7YQV+ErS9HyvS3dNXv+vlUi5hbhduOfdnpiBuTX8Vp2eRe1ZuV1omxNi5X59Ggq4 hnEhibpBltVFVxNlTvN/W0GqEfMBdyoORxHa3KKu9DwefeYJDuK7MZ2Xa1wlNCm5uDUi xmYQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=RIQ0+oH4; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id l10si22047918pgp.92.2022.02.02.05.51.27; Wed, 02 Feb 2022 05:51:39 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=RIQ0+oH4; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234605AbiBAHfm (ORCPT + 99 others); Tue, 1 Feb 2022 02:35:42 -0500 Received: from mga18.intel.com ([134.134.136.126]:45200 "EHLO mga18.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233079AbiBAHfl (ORCPT ); Tue, 1 Feb 2022 02:35:41 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1643700941; x=1675236941; h=message-id:date:mime-version:subject:to:cc:references: from:in-reply-to:content-transfer-encoding; bh=SRYaiFMBny6ljAarJROz1RKcPtjybKoMtdHqG8tHxDw=; b=RIQ0+oH4HD+jUzNiGGF0KuTMns39glltEfmKbEhs8Q8OMIZ9OGus8wn4 M4nr0ChoDjemLlpbE3SG6+9fc3D1/tFMUxtuwYjLcM1Ai3qUyhDO7Q0tL pMWPGeQ6sfClwLWw7r2NccahGqmfY+g0Ws7Fo44hFQM+8W2qmW+bGyzrg BuLmz8QD7E2CLUtDcLsPa7dE4fjhxksxluq70kKc0O7oJsMnLDvwoshx3 7ouIRDj9QzOANCCCdFUYJv1vNXA4KGLj9AzVmvQ0swAvOOrq3Tlb4X/H3 2UqJBboO+6XwaFR2ro6TURle4NuXsSR6OttVAw2qjNsCy5cQeBrNI9cpY Q==; X-IronPort-AV: E=McAfee;i="6200,9189,10244"; a="231207739" X-IronPort-AV: E=Sophos;i="5.88,333,1635231600"; d="scan'208";a="231207739" Received: from orsmga007.jf.intel.com ([10.7.209.58]) by orsmga106.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 31 Jan 2022 23:35:41 -0800 X-IronPort-AV: E=Sophos;i="5.88,333,1635231600"; d="scan'208";a="522966414" Received: from abaydur-mobl1.ccr.corp.intel.com (HELO [10.249.225.106]) ([10.249.225.106]) by orsmga007-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 31 Jan 2022 23:35:38 -0800 Message-ID: <2f61c060-0020-8e55-130d-98e59321010a@linux.intel.com> Date: Tue, 1 Feb 2022 10:35:16 +0300 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.5.1 Subject: Re: [PATCH v13 05/16] perf record: Introduce thread local variable Content-Language: en-GB To: Arnaldo Carvalho de Melo Cc: Jiri Olsa , Namhyung Kim , Alexander Shishkin , Peter Zijlstra , Ingo Molnar , linux-kernel , Andi Kleen , Adrian Hunter , Alexander Antonov , Alexei Budankov , Riccardo Mancini References: <0d127555219991c1dcd6c6bb76b24fa6b78d2932.1642440724.git.alexey.v.bayduraev@linux.intel.com> From: "Bayduraev, Alexey V" Organization: Intel Corporation In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 01.02.2022 0:45, Arnaldo Carvalho de Melo wrote: > Em Mon, Jan 17, 2022 at 09:34:25PM +0300, Alexey Bayduraev escreveu: >> Introduce thread local variable and use it for threaded trace streaming. >> Use thread affinity mask instead of record affinity mask in affinity >> modes. Use evlist__ctlfd_update() to propagate control commands from >> thread object to global evlist object to enable evlist__ctlfd_* >> functionality. Move waking and sample statistic to struct record_thread >> and introduce record__waking function to calculate the total number of >> wakes. SNIP >> if (record__open(rec) != 0) { >> err = -1; >> - goto out_child; >> + goto out_free_threads; >> } SNIP >> >> out_child: >> - evlist__finalize_ctlfd(rec->evlist); >> + record__stop_threads(rec); >> record__mmap_read_all(rec, true); >> +out_free_threads: >> record__free_thread_data(rec); >> + evlist__finalize_ctlfd(rec->evlist); > > You changed the calling order, moving evlist__finalize_ctlfd to after > record__mmap_read_all, is that ok? And if so, should be in a separate > patch, right? This is necessary because record__mmap_read_all() must be right after record__stop_threads() to prevent data loss, but we must deinitialize ctlfd after out_free_threads as it was initialized in record__open() record__mmap_read_all() looks independent of evlist__finalize_ctlfd() but I think any deinitialization in evlist would be safer after record__mmap_read_all() Probably adding such notes to this patch will be enough. Regards, Alexey > > - Arnaldo > >> record__aio_mmap_read_sync(rec); >> >> if (rec->session->bytes_transferred && rec->session->bytes_compressed) { >> @@ -3164,17 +3224,6 @@ int cmd_record(int argc, const char **argv) >> >> symbol__init(NULL); >> >> - if (rec->opts.affinity != PERF_AFFINITY_SYS) { >> - rec->affinity_mask.nbits = cpu__max_cpu().cpu; >> - rec->affinity_mask.bits = bitmap_zalloc(rec->affinity_mask.nbits); >> - if (!rec->affinity_mask.bits) { >> - pr_err("Failed to allocate thread mask for %zd cpus\n", rec->affinity_mask.nbits); >> - err = -ENOMEM; >> - goto out_opts; >> - } >> - pr_debug2("thread mask[%zd]: empty\n", rec->affinity_mask.nbits); >> - } >> - >> err = record__auxtrace_init(rec); >> if (err) >> goto out; >> @@ -3323,7 +3372,6 @@ int cmd_record(int argc, const char **argv) >> >> err = __cmd_record(&record, argc, argv); >> out: >> - bitmap_free(rec->affinity_mask.bits); >> evlist__delete(rec->evlist); >> symbol__exit(); >> auxtrace_record__free(rec->itr); >> -- >> 2.19.0 >