From patchwork Tue Aug 21 19:06:58 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Kashyap Desai X-Patchwork-Id: 10572305 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id F0BA8921 for ; Tue, 21 Aug 2018 19:07:06 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id EAA9A2945D for ; Tue, 21 Aug 2018 19:07:06 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id DE4082A9B9; Tue, 21 Aug 2018 19:07:06 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-8.0 required=2.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,RCVD_IN_DNSWL_HI autolearn=unavailable version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id E99612A9B6 for ; Tue, 21 Aug 2018 19:07:00 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727299AbeHUW2W (ORCPT ); Tue, 21 Aug 2018 18:28:22 -0400 Received: from mail-it0-f41.google.com ([209.85.214.41]:51830 "EHLO mail-it0-f41.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727206AbeHUW2W (ORCPT ); Tue, 21 Aug 2018 18:28:22 -0400 Received: by mail-it0-f41.google.com with SMTP id e14-v6so5663492itf.1 for ; Tue, 21 Aug 2018 12:07:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=broadcom.com; s=google; h=mime-version:from:date:message-id:subject:to :content-transfer-encoding; bh=gi6DEyesUx8IB8tiGrVGpvVAHKtEB5j/F+wBC7qeNx8=; b=SHRNGDL+vT17ZfUv06wL14Gttx8J2ReklB6FaMD8C6D3lvIQAiEzOTX3Qh35qUvRRD A6+PPBI7pybCqeB4QhhfhNTe11I5+wrGPpF3hBXOR6bjf5OXaMqRpxmoRe5sE3bp4vrg MjuXC1e25RkltoinGyW3cBbGXYmlU7OsyFoVo= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to :content-transfer-encoding; bh=gi6DEyesUx8IB8tiGrVGpvVAHKtEB5j/F+wBC7qeNx8=; b=fpfYbB8U+0ulJZtDk8DrBcNEIyKPbDHw6T1O+6TA9+uHEZjlI+fhuKLNkvCIlgBgPa eLJ6y/w22CjT7BMTIIgLmzRjDmfRRNfeZKtOFVsqTpNPS3/o+aH8hR6oFqM/3Xn3gUO+ 7DOCK+ha9sl+zbuXeeLLdWsHMeTOlxA0q0Z3MAMW88plpdRhm9Y96UZ0kb4oXFKjMQul fb9dg6hDxQOIWU2eZ7miMrgxThYjfRvPl1DrlwJvQzWD+sjatnNKLz0/gAFp4D4q+Bsw ydq2r+hijKyErax4bHsjLaKR4X5Y86zxfsUSqpBxzRK7YLcU7iCfniW3Rcypujp8tABB /Bkw== X-Gm-Message-State: APzg51D+zsrztmKBxADI0dUhCCZ28X738kkdE8so82wjYeSzCDrUeH3h ShwyUnErmmLwRmGFu05a/PlA+0f+O3FGyepDyIh3DtQ+ITE= X-Google-Smtp-Source: ANB0VdYFUQYzXoY/sL5Vwztu5+GIdoP5HN+gJ9bV+OlJ/9unywBuooIqUC94Bmkg6TvWP4XMJDd272okcF01Ax0Q6+E= X-Received: by 2002:a24:eec7:: with SMTP id b190-v6mr597587iti.32.1534878419153; Tue, 21 Aug 2018 12:06:59 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a02:4c07:0:0:0:0:0 with HTTP; Tue, 21 Aug 2018 12:06:58 -0700 (PDT) From: Kashyap Desai Date: Tue, 21 Aug 2018 13:06:58 -0600 Message-ID: Subject: [RFC0/1] megaraid_sas : IRQ polling using threaded interrupt To: linux-scsi , linux-block@vger.kernel.org, Peter Rivera , Steve Hagan Sender: linux-scsi-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-scsi@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP Hi, I refer below thread for interrupt polling related discussion for storage devices (NVME/HBA). http://lists.infradead.org/pipermail/linux-nvme/2017-January/007749.html I am trying to evaluate the similar concept to reduce interrupts using irq-poll and threaded ISR. Below is high level changes I did in my experiment. In megaraid_sas driver, I schedule irq poll using “irq_poll_sched” and disable that particular IRQ line. I was expecting more completion after I disable irq line, but in most of the cases just one completion happened from irq poll context. It must be due to host side processing is much faster than IO processing at back end device. Similar observation was posted in above mentioned thread as well. I added manual wait using “udelay()” and wait for some more time in irq poll context. Using additional wait, I am able to reduce interrupt per seconds and performance impact on latency is not visible since I choose udelay(1). One drawback I see is overall CPU utilization goes up since driver is using extra delay to reduce interrupts. To overcome CPU utilization issue, I switch to threaded ISR and replace udelay() with usleep(). Using threaded interrupt based polling CPU utilization goes to normal. I am trying to understand what is a drawback using threaded ISR and doing interrupt polling from threaded ISR. One problem I understood is threaded ISR can be preempted by other high priority context (most likely soft/hard interrupt). If threaded interrupt is running on some CPU-x and some other device is also requesting interrupt on same CPU-x, there can be latency introduced because CPU-x will complete ISR before it can run threaded ISR. Thanks ,Kashyap