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=-3.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS autolearn=no 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 CA847C2D0E4 for ; Mon, 23 Nov 2020 13:24:28 +0000 (UTC) Received: from alsa0.perex.cz (alsa0.perex.cz [77.48.224.243]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id C1B6A204EC for ; Mon, 23 Nov 2020 13:24:26 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=alsa-project.org header.i=@alsa-project.org header.b="CSUNqNbE" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org C1B6A204EC Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=suse.de Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=alsa-devel-bounces@alsa-project.org Received: from alsa1.perex.cz (alsa1.perex.cz [207.180.221.201]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by alsa0.perex.cz (Postfix) with ESMTPS id 0ECC2165E; Mon, 23 Nov 2020 14:23:34 +0100 (CET) DKIM-Filter: OpenDKIM Filter v2.11.0 alsa0.perex.cz 0ECC2165E DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=alsa-project.org; s=default; t=1606137864; bh=KIpmGtXQateMrrO9mCj7uVc/zWg+6lOepnclTwLoCt4=; h=Date:From:To:Subject:In-Reply-To:References:Cc:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From; b=CSUNqNbEgZ9q3z3JQLlxZiPFpOvkP6ILpPUOCX06XkZIMttdLhtO1Si4g67uY3hNQ JZ8T7DWyPWfB2wjLGI4CxyfbPaJs8r5kdsNhC47bhi4tlKVKmN3vGysHzOHyvr8EM5 Q9KmBUWqJaCGx3eHPeFcweTaOfUk1+JrjUjnOYR0= Received: from alsa1.perex.cz (localhost.localdomain [127.0.0.1]) by alsa1.perex.cz (Postfix) with ESMTP id 98F68F8015F; Mon, 23 Nov 2020 14:23:33 +0100 (CET) Received: by alsa1.perex.cz (Postfix, from userid 50401) id 08736F80255; Mon, 23 Nov 2020 14:23:32 +0100 (CET) Received: from mx2.suse.de (mx2.suse.de [195.135.220.15]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by alsa1.perex.cz (Postfix) with ESMTPS id C6A97F80113 for ; Mon, 23 Nov 2020 14:23:24 +0100 (CET) DKIM-Filter: OpenDKIM Filter v2.11.0 alsa1.perex.cz C6A97F80113 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id F3649AD12; Mon, 23 Nov 2020 13:23:18 +0000 (UTC) Date: Mon, 23 Nov 2020 14:23:18 +0100 Message-ID: From: Takashi Iwai To: Michael Nazzareno Trimarchi Subject: Re: Poor performace on mmap reading arm64 on audio device In-Reply-To: References: User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI/1.14.6 (Maruoka) FLIM/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL/10.8 Emacs/25.3 (x86_64-suse-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: Nicolin Chen , Linux-ALSA , Mark Brown X-BeenThere: alsa-devel@alsa-project.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Alsa-devel mailing list for ALSA developers - http://www.alsa-project.org" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: alsa-devel-bounces@alsa-project.org Sender: "Alsa-devel" On Sat, 21 Nov 2020 10:40:04 +0100, Michael Nazzareno Trimarchi wrote: > > Hi all > > I'm trying to figure out how to increase performance on audio reading > using the mmap interface. Right now what I understand it's that > allocation comes from core/memalloc.c ops that allocate the memory for > dma under driver/dma. > The reference platform I have is an imx8mm and the allocation in arm64 is: > > 0xffff800011ff5000-0xffff800012005000 64K PTE RW NX SHD > AF UXN MEM/NORMAL-NC > > This is the reason that is allocated for dma interface. > > Now access linear on the multichannel interface the performance is bad > but worse if I try to access a channel a time on read. > So it looks like it is better to copy the block using memcpy on a > cached area and then operate on a single channel sample. If it's > correct what I'm saying the mmap_begin and mmap_commit > basically they don't do anything on cache level so the page mapping > and way is used is always the same. Can the interface be modified to > allow cache the area during read and restore in the commit > phase? The current API of the mmap for the sound ring-buffer is designed to allow concurrent accesses at any time in the minimalistic kernel-user context switching. So the whole buffer is allocated as coherent and mmapped in a shot. It's pretty efficient for architectures like x86, but has disadvantages on ARM, indeed. The mmap_begin and mmap_commit are the concepts in the alsa-lib side for supporting the plugins better, and they doesn't represent kernel ABI. So, this extension would be needed at first, and the memory allocation mechanism has to be changed as well. Last but not least, the concurrency has to be reconsidered if this approach is taken. That said, it's possible in theory, but practically no trivial task. thanks, Takashi