From patchwork Wed Oct 21 06:21:17 2015 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Leon Romanovsky X-Patchwork-Id: 7454641 Return-Path: X-Original-To: patchwork-linux-rdma@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork1.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.136]) by patchwork1.web.kernel.org (Postfix) with ESMTP id 990009F30B for ; Wed, 21 Oct 2015 06:21:46 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id 822B9205BA for ; Wed, 21 Oct 2015 06:21:45 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 460C120460 for ; Wed, 21 Oct 2015 06:21:44 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753193AbbJUGVl (ORCPT ); Wed, 21 Oct 2015 02:21:41 -0400 Received: from mail-wi0-f175.google.com ([209.85.212.175]:37006 "EHLO mail-wi0-f175.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753153AbbJUGVk (ORCPT ); Wed, 21 Oct 2015 02:21:40 -0400 Received: by wicfv8 with SMTP id fv8so59155749wic.0 for ; Tue, 20 Oct 2015 23:21:39 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:date:message-id; bh=yMmazi7VWEe19jah2xa7N9CiDqK6ww06WUv+JCr1WJY=; b=SWHgz5R4ZYrzLTfWOapZFUlg097VtOklwa4qjjFRtREbIBG6mb361gsLlW32kkWTHN RM7wrHkt8+HoAckyv07i74iheFTd1Sb2Ry2eE0/gOp7zD57CP0P7T/QtaPVxDYYVvaQ7 9Op7tge0ENWWOS/tOHGq43W2ZyBCBh9c0JK0HVRfkyGBn2cXL9tktXVcBbzANBpGo1S0 yzdpLEGyqhGFoBTQU5fE7y5Qw35FJw311wD7QSEMlmcOzquhf8UhCdEhduPmanI94XRI 3jxZED+fxoTUxwQQfrRxUwDZ88IwAiN7j9yxzBYtWroTMz3RHTm5+dzvdgRRYj8jqczx Np4A== X-Gm-Message-State: ALoCoQmAJy4PgaPw3NkWYx5QKryn4WA5RnaWY9ptIw5d6UbAryXmhOJZUVUULxKNtmE0adBAbXOx X-Received: by 10.180.8.226 with SMTP id u2mr15618019wia.90.1445408499379; Tue, 20 Oct 2015 23:21:39 -0700 (PDT) Received: from localhost ([213.57.247.249]) by smtp.gmail.com with ESMTPSA id jj8sm5838523wid.2.2015.10.20.23.21.38 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 20 Oct 2015 23:21:38 -0700 (PDT) From: Leon Romanovsky To: dledford@redhat.com Cc: sean.hefty@intel.com, linux-rdma@vger.kernel.org, Leon Romanovsky , Eli Cohen Subject: [PATCH] IB/mlx5: Postpone remove_keys under knowledge of coming preemption Date: Wed, 21 Oct 2015 09:21:17 +0300 Message-Id: <1445408477-24886-1-git-send-email-leon@leon.nu> X-Mailer: git-send-email 2.1.4 Sender: linux-rdma-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-rdma@vger.kernel.org X-Spam-Status: No, score=-6.9 required=5.0 tests=BAYES_00, RCVD_IN_DNSWL_HI, RP_MATCHES_RCVD, UNPARSEABLE_RELAY autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP From: Leon Romanovsky The remove_keys() logic is performed as garbage collection task. Such task is intended to be run when no other active processes are running. The need_resched() will return TRUE if there are user tasks to be activated in near future. In such case, we don't execute remove_keys() and postpone the garbage collection work to try to run in next cycle, in order to free CPU resources to other tasks. The possible pseudo-code to trigger such scenario: 1. Allocate a lot of MR to fill the cache above the limit. 2. Wait a small amount of time "to calm" the system. 3. Start CPU extensive operations on multi-node cluster. 4. Expect performance degradation during MR cache shrink operation. Signed-off-by: Leon Romanovsky Signed-off-by: Eli Cohen --- -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html diff --git a/drivers/infiniband/hw/mlx5/mr.c b/drivers/infiniband/hw/mlx5/mr.c index 54a15b5..45ce00e 100644 --- a/drivers/infiniband/hw/mlx5/mr.c +++ b/drivers/infiniband/hw/mlx5/mr.c @@ -381,7 +381,19 @@ } } } else if (ent->cur > 2 * ent->limit) { - if (!someone_adding(cache) && + /* + * The remove_keys() logic is performed as garbage collection + * task. Such task is intended to be run when no other active + * processes are running. + * + * The need_resched() will return TRUE if there are user tasks + * to be activated in near future. + * + * In such case, we don't execute remove_keys() and postpone + * the garbage collection work to try to run in next cycle, + * in order to free CPU resources to other tasks. + */ + if (!need_resched() && !someone_adding(cache) && time_after(jiffies, cache->last_add + 300 * HZ)) { remove_keys(dev, i, 1); if (ent->cur > ent->limit)