From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_PASS,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 92173C00449 for ; Fri, 5 Oct 2018 11:50:24 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 532CB206B2 for ; Fri, 5 Oct 2018 11:50:24 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 532CB206B2 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=linux.intel.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728443AbeJESsq (ORCPT ); Fri, 5 Oct 2018 14:48:46 -0400 Received: from mga17.intel.com ([192.55.52.151]:53979 "EHLO mga17.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728003AbeJESsq (ORCPT ); Fri, 5 Oct 2018 14:48:46 -0400 X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga008.jf.intel.com ([10.7.209.65]) by fmsmga107.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 05 Oct 2018 04:50:22 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.54,344,1534834800"; d="scan'208";a="78970411" Received: from linux.intel.com ([10.54.29.200]) by orsmga008.jf.intel.com with ESMTP; 05 Oct 2018 04:50:06 -0700 Received: from [10.125.251.251] (abudanko-mobl.ccr.corp.intel.com [10.125.251.251]) by linux.intel.com (Postfix) with ESMTP id D1B55580332; Fri, 5 Oct 2018 04:50:03 -0700 (PDT) Subject: Re: [PATCH v9 2/3]: perf record: enable asynchronous trace writing To: Namhyung Kim Cc: Peter Zijlstra , Ingo Molnar , Arnaldo Carvalho de Melo , Alexander Shishkin , Jiri Olsa , Andi Kleen , linux-kernel , kernel-team@lge.com References: <5ed78452-ff2b-dfe5-ec29-888971cb4b55@linux.intel.com> <20181005071615.GC3768@sejong> <20181005084854.GE3768@sejong> <4ee1c347-674b-ac61-65cf-55fb71a7cc2b@linux.intel.com> <20181005105557.GF3768@sejong> From: Alexey Budankov Organization: Intel Corp. Message-ID: Date: Fri, 5 Oct 2018 14:50:01 +0300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <20181005105557.GF3768@sejong> 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, On 05.10.2018 13:55, Namhyung Kim wrote: > On Fri, Oct 05, 2018 at 12:39:10PM +0300, Alexey Budankov wrote: >> >> It still have to adjust the file pos thru lseek() prior leaving >> record__aio_pushfn() so space in trace file would be pre-allocated for >> enqueued record and file pos be moved beyond the record data, >> possibly for the next record. > > For that purpose, isn't it better calling ftruncate() with a > reasonable batch size to reduce number of syscalls? > According to docs [1] ftruncate() does not advance file pos which is essential here. > >> Well, if it has AIO symbols + opts.nr_cblocks exposed unconditionally of >> HAVE_AIO_SUPPORT, but keeps the symbols implementation under the define, then >> as far aio-cblocks option is not exposed thru command line, we end up in >> whole bunch of symbols referenced under the else branch that, after all, >> can cause Perf binary size increase, which is, probably, worth avoiding. > > I think it's ok as long as they're empty. Well, the both designs are possible and acceptable. The only thing that matters here is contradictive requests from other reviewing folks. Let me share the version without dummy functions so we could jointly decide how to proceed from there. Ok? Thanks, Alexey [1] http://man7.org/linux/man-pages/man2/ftruncate.2.html