Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754905AbbLVLkS (ORCPT ); Tue, 22 Dec 2015 06:40:18 -0500 Received: from lxorguk.ukuu.org.uk ([81.2.110.251]:41929 "EHLO lxorguk.ukuu.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752261AbbLVLkQ (ORCPT ); Tue, 22 Dec 2015 06:40:16 -0500 Date: Tue, 22 Dec 2015 11:39:03 +0000 From: One Thousand Gnomes To: Finn Thain Cc: "James E.J. Bottomley" , Michael Schmitz , , , , "Martin K. Petersen" , Russell King , linux-arm-kernel@lists.infradead.org Subject: Re: [PATCH v3 66/77] ncr5380: Fix soft lockups Message-ID: <20151222113903.06422dbe@lxorguk.ukuu.org.uk> In-Reply-To: <20151222011755.965510468@telegraphics.com.au> References: <20151222011737.980475848@telegraphics.com.au> <20151222011755.965510468@telegraphics.com.au> Organization: Intel Corporation X-Mailer: Claws Mail 3.12.0 (GTK+ 2.24.28; x86_64-redhat-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1348 Lines: 29 On Tue, 22 Dec 2015 12:18:44 +1100 Finn Thain wrote: > Because of the rudimentary design of the chip, it is necessary to poll the > SCSI bus signals during PIO and this tends to hog the CPU. The driver will > accept new commands while others execute, and this causes a soft lockup > because the workqueue item will not terminate until the issue queue is > emptied. > > When exercising dmx3191d using sequential IO from dd, the driver is sent > 512 KiB WRITE commands and 128 KiB READs. For a PIO transfer, the rate is > is only about 300 KiB/s, so these are long-running commands. And although > PDMA may run at several MiB/s, interrupts are disabled for the duration > of the transfer. > > Fix the unresponsiveness and soft lockup issues by calling cond_resched() > after each command is completed and by limiting max_sectors for drivers > that don't implement real DMA. Is there a reason for not doing some limiting in the DMA case too. A 512K write command even with DMA on a low end 68K box introduces a second of latency before another I/O can be scheduled ? Alan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/