Received: by 2002:a05:6a10:413:0:0:0:0 with SMTP id 19csp752546pxp; Fri, 11 Mar 2022 14:12:05 -0800 (PST) X-Google-Smtp-Source: ABdhPJyBL/gMKhJU4cSIeXs2nqG/nThV5AZ679Z5DKQShdkABupR5mc4vg3h1W6Pz8ImsYrryFX3 X-Received: by 2002:a63:2dc7:0:b0:380:ccca:93bc with SMTP id t190-20020a632dc7000000b00380ccca93bcmr10204736pgt.168.1647036725508; Fri, 11 Mar 2022 14:12:05 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1647036725; cv=none; d=google.com; s=arc-20160816; b=y0nCoPHpFxqOw3TdDR/HkjYwfkENJn6kG80wYRLj/QmdXv5TjB0N+BH5k9Gnkae/3K 5KeYe73neRBUZ2c7IsAZ51kqmVGNHXAkCo41WjrCUU3sc+3FNQpxIiuHYzsARTq2H8p7 rkyT+juABE/oXY7PInwPRpyVY1XutQ8rVhFJgQu9KzxkNWAyrB2y7zq5d4Wo7JJ/xVlL EnbsNndKhqYHdP2Uv3Woh6QNYnA27jNHX0BRAjqz0UZ+ZkgyNOB0anrgwW2nF7FS+LRA QenIeTwQ37USVSRWC3IkQfLZ9PU5kJyotZJ+dPneYh1xbPza4OKJ/ejVceb0loiXnh5U dHFw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from :dkim-signature; bh=wwTJn+zL0dqfQDKqgI1+yZjXf8AI1FOrDl4iHd/5JvA=; b=AqqHe5BWINVvOOV+4oL0C2dNGNEVIWbW9U/XK9M4Cc21wj1BXGq34/7H40OAoNMlHo 69S0EJrBbdoh43QCYpvkPJch475OORjeCPJQlRw6hlHV5eIUgUxkFORCzPUfy1C6voTT 88m40EzDaQH1VuHaKCCu4eE1flTHob79cms/GcjfnVECWbIlubn6WDYib4MvUr6RQ2TA X94H0MZ6LwGdanYK6GWBJD1WaoIr/2Df9apIvk4O4hikcmfNNNpSWk5PlxP2hlj5JZQt pOFSxckgtKpD+zegCqmjMUrG9mY68GPOJN5ocGlNx//zmPN7nwNSfSKuClX6g0zFArKO IuGA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=bCsFg8cM; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from lindbergh.monkeyblade.net (lindbergh.monkeyblade.net. [2620:137:e000::1:18]) by mx.google.com with ESMTPS id nl12-20020a17090b384c00b001c4ea95a3bfsi2357236pjb.63.2022.03.11.14.12.05 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 11 Mar 2022 14:12:05 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) client-ip=2620:137:e000::1:18; Authentication-Results: mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=bCsFg8cM; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id CCA4E2E1DF8; Fri, 11 Mar 2022 13:28:04 -0800 (PST) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S245503AbiCJUuH (ORCPT + 99 others); Thu, 10 Mar 2022 15:50:07 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:34492 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S243957AbiCJUuF (ORCPT ); Thu, 10 Mar 2022 15:50:05 -0500 Received: from mga04.intel.com (mga04.intel.com [192.55.52.120]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 82AD5186452 for ; Thu, 10 Mar 2022 12:49:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1646945343; x=1678481343; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=XBV/vhSpOQFq3ItxNWH3aLVfSt1M13WXm1fnUUqRboI=; b=bCsFg8cMjIoxUDOBKfKaUlZuG8faa1JpG2/qO1PSRI6CJscLdsvcUl0R noAEYz3J8FTSLC+CTJpGiErUY7RPypBl9tJNoqOkPjsMQFjGXhMpWmPMW J/z9NK4WOLeTHQ4spQ4KYW/2nyncXgj9rNSmYLl6cm/4/+sh0puG2vI9i +/GScGItfNuJYrqmow2gf3ObkVF723IyQNl8uf9ZnmzrDUYjcDZ9Us/UK NypCkDj6lKirl3WqnqYhHTAKwlYxQz33ce4hTNBSsWMyKSESlZVKAr2J1 bUcrFrJnJoFNmRgVTK3hcxLvGxH0GtUQzcmOEK5KJCbLTUytGsYHT3tmD Q==; X-IronPort-AV: E=McAfee;i="6200,9189,10282"; a="254205623" X-IronPort-AV: E=Sophos;i="5.90,171,1643702400"; d="scan'208";a="254205623" Received: from orsmga008.jf.intel.com ([10.7.209.65]) by fmsmga104.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 10 Mar 2022 12:49:03 -0800 X-IronPort-AV: E=Sophos;i="5.90,171,1643702400"; d="scan'208";a="554843291" Received: from agluck-desk3.sc.intel.com ([172.25.222.60]) by orsmga008-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 10 Mar 2022 12:49:02 -0800 From: Tony Luck To: Thomas Gleixner Cc: Fenghua Yu , x86@kernel.org, linux-kernel@vger.kernel.org, patches@lists.linux.dev, Tony Luck Subject: [PATCH v2 0/2] Make life miserable for split lockers Date: Thu, 10 Mar 2022 12:48:52 -0800 Message-Id: <20220310204854.31752-1-tony.luck@intel.com> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220217012721.9694-1-tony.luck@intel.com> References: <20220217012721.9694-1-tony.luck@intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-2.4 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RDNS_NONE,SPF_HELO_NONE,T_SCC_BODY_TEXT_LINE autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org See part 0001 commit message for what & why. Changes since v1(RFC) based on feedback from Thomas: 1) No longer implemented as new sub-option of split_lock_detect boot option. Just update the existing (default) "warn" mode. 2) Use the (more appropriate) "schedule_delayed_work_on() instead of schedule_delayed_work() to re-enable split lock detection. 3) Add msleep for extra misery before disabling split lock detection on a core. Next two aren't from Thomas. 4) Drop the TIF_SLD bit and associated code. No longer needed. This part is done as clean up in patch 0002. 5) Add a bit in task structure to make sure each split-locking task only tries to print a warn message to the console once. Need this to preserve existing behavior that was previously controlled by the TIF_SLD bit. Testing notes. I checked this out by running 2,000 processes that each looped executing 10,000 split locks. System remains very responsive while this test is running (compared with unusable without these patches). When each process gets the semaphore and two jiffies of time to execute split locks it manages to complete ~430 before the delayed work thread re-enables detection. The semaphore gives nice round-robin access to the 2,000 tasks. So each ends up blocking for 24ish seconds while the other 1,999 task take their turn. Tony Luck (2): x86/split_lock: Make life miserable for split lockers x86/split-lock: Remove unused TIF_SLD bit arch/x86/include/asm/cpu.h | 2 - arch/x86/include/asm/thread_info.h | 4 +- arch/x86/kernel/cpu/intel.c | 77 +++++++++++++++++++++--------- arch/x86/kernel/process.c | 3 -- include/linux/sched.h | 3 ++ kernel/fork.c | 5 ++ 6 files changed, 64 insertions(+), 30 deletions(-) -- 2.35.1