Received: by 2002:ac0:aed5:0:0:0:0:0 with SMTP id t21csp3970236imb; Wed, 6 Mar 2019 01:58:24 -0800 (PST) X-Google-Smtp-Source: APXvYqysI/1o9jnj3wjIxLlrrIOSG7sWYgirXW93L9DNHdGT/dqxjOTFJwNerIZlunWVb4spWj+O X-Received: by 2002:a63:6e02:: with SMTP id j2mr5329664pgc.229.1551866304863; Wed, 06 Mar 2019 01:58:24 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1551866304; cv=none; d=google.com; s=arc-20160816; b=wHCjDB8HmM7zowW9HOkxg9s/hEa2HvRNGGf3YsfkObqXhZK1WS/eiwpUR8HyyqEuT5 fRJSoC3u0ukNAa/bsYTHBI5PuvRsYlMbKxULt8qYyX+d4ZcbinL44BKp13jZayvovQnt dSZXAHgrMoT/CkPImwRQQsw5787UMy0SuYL9LOlIZmBrLDA163iqpbvphE2lDJuKZtXV 1ENTH8UZ2z8R6lzZCmSJTFlwb+6CFwLy1c+WSNdLIGSK0TsZU8YuzP4a9GEJwBVA6mZz 8RaBNqnWBVKxAVJVnhNL4Ez86/Cj13bc0tCTx4rqdOjEmcWXRnE374tqVDT+JQPnu7Kn aJ+A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject:dkim-signature; bh=EWdfRDkR47h5farf8flW3tudH2mBH1OHkT3I7G7iNNM=; b=W0+3280sSSUTq+enhdC+ZYlrsRc2MLmvTEJkXzY9bFXngraw9Ju4R2tSArkZJSPVFd OwyGH7I9kvp5TntzcFr7vcXPU97bvj0YCEM5yAUmLAbw1aU3BTXDZLsJtdKZd98ASEtk 178F6wzKbSXPYI10wX7jd6nFLS6lJEndknan4pA5htjQPZT0yAmJnI87faT7VRkeK+dq JFT2mI4JEppKPmXLal2NdmBbsqhtwrcvCzei8+nS5eoZ/DU0s0GiRm/fOLEpgaiwf227 BxdmNZT21Ot6jpyiyW255NG6yM1XKKEeHbOdkCZXu5zv3yD9WnKbdKWkZc6k1hZixn1w Treg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@ti.com header.s=ti-com-17Q1 header.b=oLunVfSc; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=QUARANTINE sp=NONE dis=NONE) header.from=ti.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id r203si1037086pgr.517.2019.03.06.01.58.09; Wed, 06 Mar 2019 01:58:24 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@ti.com header.s=ti-com-17Q1 header.b=oLunVfSc; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=QUARANTINE sp=NONE dis=NONE) header.from=ti.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729973AbfCFJ5B (ORCPT + 99 others); Wed, 6 Mar 2019 04:57:01 -0500 Received: from lelv0143.ext.ti.com ([198.47.23.248]:43866 "EHLO lelv0143.ext.ti.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726596AbfCFJ46 (ORCPT ); Wed, 6 Mar 2019 04:56:58 -0500 Received: from fllv0034.itg.ti.com ([10.64.40.246]) by lelv0143.ext.ti.com (8.15.2/8.15.2) with ESMTP id x269upRa091145; Wed, 6 Mar 2019 03:56:51 -0600 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ti.com; s=ti-com-17Q1; t=1551866211; bh=EWdfRDkR47h5farf8flW3tudH2mBH1OHkT3I7G7iNNM=; h=Subject:To:CC:References:From:Date:In-Reply-To; b=oLunVfScC9+SYhtfQSXU0ryGTsLTEcONNWchXOtNvd4MTznpCAa7vf3ZxJmWt338/ niq2lvdh9kDQvZ+TeMpiU5WOwIDpMBar1hZ2UH+TDeX9X1MmmIxPf95xi6/7OtkChe +L066CP5emSVdB+zpxWw3ETYkbSE4u120u/1sk4g= Received: from DLEE100.ent.ti.com (dlee100.ent.ti.com [157.170.170.30]) by fllv0034.itg.ti.com (8.15.2/8.15.2) with ESMTPS id x269uo0J122855 (version=TLSv1.2 cipher=AES256-GCM-SHA384 bits=256 verify=FAIL); Wed, 6 Mar 2019 03:56:50 -0600 Received: from DLEE101.ent.ti.com (157.170.170.31) by DLEE100.ent.ti.com (157.170.170.30) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1591.10; Wed, 6 Mar 2019 03:56:49 -0600 Received: from dflp32.itg.ti.com (10.64.6.15) by DLEE101.ent.ti.com (157.170.170.31) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_RSA_WITH_AES_256_CBC_SHA) id 15.1.1591.10 via Frontend Transport; Wed, 6 Mar 2019 03:56:49 -0600 Received: from [172.24.190.215] (ileax41-snat.itg.ti.com [10.172.224.153]) by dflp32.itg.ti.com (8.14.3/8.13.8) with ESMTP id x269ukPG021936; Wed, 6 Mar 2019 03:56:47 -0600 Subject: Re: [PATCH v2 1/8] mmc: sdhci: Get rid of finish_tasklet To: Adrian Hunter , , , , CC: , , , , References: <20190215192033.24203-1-faiz_abbas@ti.com> <20190215192033.24203-2-faiz_abbas@ti.com> From: Faiz Abbas Message-ID: <8d72ff93-e07f-52b9-da85-acd54f046694@ti.com> Date: Wed, 6 Mar 2019 15:30:06 +0530 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8" Content-Language: en-US Content-Transfer-Encoding: 7bit X-EXCLAIMER-MD-CONFIG: e1e8a2fd-e40a-4ac6-ac9b-f7e9cc9ee180 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Adrian, On 25/02/19 1:47 PM, Adrian Hunter wrote: > On 15/02/19 9:20 PM, Faiz Abbas wrote: >> sdhci.c has two bottom halves implemented. A threaded_irq for handling >> card insert/remove operations and a tasklet for finishing mmc requests. >> With the addition of external dma support, dmaengine APIs need to >> terminate in non-atomic context before unmapping the dma buffers. >> >> To facilitate this, remove the finish_tasklet and move the call of >> sdhci_request_done() to the threaded_irq() callback. > > The irq thread has a higher latency than the tasklet. The performance drop > is measurable on the system I tried: > > Before: > > # dd if=/dev/mmcblk1 of=/dev/null bs=1G count=1 & > 1+0 records in > 1+0 records out > 1073741824 bytes (1.1 GB) copied, 4.44502 s, 242 MB/s > > After: > > # dd if=/dev/mmcblk1 of=/dev/null bs=1G count=1 & > 1+0 records in > 1+0 records out > 1073741824 bytes (1.1 GB) copied, 4.50898 s, 238 MB/s > > So we only want to resort to the thread for the error case. > Sorry for the late response here, but this is about 1.6% decrease. I tried out the same commands on a dra7xx board here (with about 5 consecutive dd of 1GB) and the average decrease was 0.3%. I believe you will also find a lesser percentage change if you average over multiple dd commands. Is this really so significant that we have to maintain two different bottom halves and keep having difficulty with adding APIs that can sleep? Also I am not sure how to implement only the error handling part in the threaded_irq. We need to enter sdhci_request_done() and get the current mrq before we can check for error conditions like I've done in patch 2: /* Terminate and synchronize dma in case of an error */ if (data && (mrq->cmd->error || data->error) && host->use_external_dma) { struct dma_chan *chan = sdhci_external_dma_channel(host, data); dmaengine_terminate_sync(chan); } On a related note, do we really need to protect everything in sdhci_request_done() with spinlocks? In patch 2 I have only removed lock for the terminate_sync() parts that I added but the whole dma_unmap/dma_sync parts should be left unprotected IMO. Thanks, Faiz