From patchwork Mon Jun 11 18:44:44 2012 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Benjamin Collins X-Patchwork-Id: 164265 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from chlorine.canonical.com (chlorine.canonical.com [91.189.94.204]) by ozlabs.org (Postfix) with ESMTP id 710B0B6FC3 for ; Tue, 12 Jun 2012 09:01:25 +1000 (EST) Received: from localhost ([127.0.0.1] helo=chlorine.canonical.com) by chlorine.canonical.com with esmtp (Exim 4.71) (envelope-from ) id 1SeDbq-0003Sa-4o; Mon, 11 Jun 2012 23:01:18 +0000 Received: from mail-pz0-f49.google.com ([209.85.210.49]) by chlorine.canonical.com with esmtp (Exim 4.71) (envelope-from ) id 1SeDbn-0003CA-LX for kernel-team@lists.ubuntu.com; Mon, 11 Jun 2012 23:01:15 +0000 Received: by mail-pz0-f49.google.com with SMTP id m1so6348062dad.8 for ; Mon, 11 Jun 2012 16:01:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:in-reply-to:references:from:date:subject:to; bh=FBNmsaukqd7HeCykhCNyXr+jYJB4f1RbD4m4bdurYYI=; b=OJiXh0R7xFVryplC3Yv4OilmvGBnvW1pm9LTe63PHVMoEUB91+0HHK7EKXjThyDiNo 4HZLGf0XYEHN0wjeRSFEsdGiQMznjUiO7sRQNb1i9Mkv582Bp0u5hu3oQLFIr1vr9hZ9 wIxc6WCjKG+exIeFz9n8AZ0GFtsNs72bmgoZDUk50pYyEkJyU/FozNzJuV3k9lh7gmDj eRzPR3wHy+cMPwLMYyi6cc2bZeVEnpEJX1UpIrzDzY+rYlXimo+ZWBdMCzYJDyg5/Csi wWh/S3KJGmZqVrmz31fScxcYW3TutlkSF0IMw7oy+PBA3v8VJ5lVcKAOw+WTqAo+r2o3 WA4Q== Received: by 10.68.227.227 with SMTP id sd3mr31336143pbc.53.1339455675237; Mon, 11 Jun 2012 16:01:15 -0700 (PDT) Received: from localhost (ip68-13-200-36.hr.hr.cox.net. [68.13.200.36]) by mx.google.com with ESMTPS id ka5sm19930754pbb.37.2012.06.11.16.01.12 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 11 Jun 2012 16:01:14 -0700 (PDT) Received: by localhost (sSMTP sendmail emulation); Mon, 11 Jun 2012 19:01:09 -0400 Message-Id: In-Reply-To: References: From: Ben Collins Date: Mon, 11 Jun 2012 14:44:44 -0400 Subject: [PATCH 06/27] UBUNTU: [Upstream] SCSI: AACRAID: Relax the tight timeout loop on fib commands To: kernel-team@lists.ubuntu.com X-BeenThere: kernel-team@lists.ubuntu.com X-Mailman-Version: 2.1.13 Precedence: list List-Id: Kernel team discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Sender: kernel-team-bounces@lists.ubuntu.com Errors-To: kernel-team-bounces@lists.ubuntu.com The loop that waited for syncronous fib commands was causing a CPU stall when a timeout actually occured. 1) Switch to using a more accurate timeout mechanism. 2) Do not pace the loop with udelay(). Use cpu_relax() to allow for scheduling to occur. Signed-off-by: Ben Collins Cc: Adaptec OEM Raid Solutions event_wait)) { int blink; - if (--count == 0) { + if (time_is_before_eq_jiffies(timeout)) { struct aac_queue * q = &dev->queues->queue[AdapNormCmdQueue]; spin_lock_irqsave(q->lock, qflags); q->numpending--; @@ -588,7 +588,10 @@ int aac_fib_send(u16 command, struct fib *fibptr, unsigned long size, } return -EFAULT; } - udelay(5); + /* We used to udelay() here but that absorbed + * a CPU when a timeout occured. Not very + * useful. */ + cpu_relax(); } } else if (down_interruptible(&fibptr->event_wait)) { /* Do nothing ... satisfy