Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751643AbdHPOxy convert rfc822-to-8bit (ORCPT ); Wed, 16 Aug 2017 10:53:54 -0400 Received: from mga06.intel.com ([134.134.136.31]:20780 "EHLO mga06.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751089AbdHPOxx (ORCPT ); Wed, 16 Aug 2017 10:53:53 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.41,383,1498546800"; d="scan'208";a="124254624" From: "Luck, Tony" To: Thomas Gleixner , Vikas Shivappa CC: "Shivappa, Vikas" , "x86@kernel.org" , "linux-kernel@vger.kernel.org" , "hpa@zytor.com" , "peterz@infradead.org" , "Shankar, Ravi V" , "Yu, Fenghua" , "ak@linux.intel.com" , "eranian@google.com" , "davidcc@google.com" Subject: RE: [PATCH 1/2] x86/intel_rdt/mbm: Fix MBM overflow handler during hot cpu Thread-Topic: [PATCH 1/2] x86/intel_rdt/mbm: Fix MBM overflow handler during hot cpu Thread-Index: AQHTFirRxF/MG2eKTU24+fmVpmJpbaKHKpyA///mSVA= Date: Wed, 16 Aug 2017 14:53:52 +0000 Message-ID: <3908561D78D1C84285E8C5FCA982C28F61340139@ORSMSX114.amr.corp.intel.com> References: <1502845243-20454-1-git-send-email-vikas.shivappa@linux.intel.com> <1502845243-20454-2-git-send-email-vikas.shivappa@linux.intel.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 10.0.102.7 dlp-reaction: no-action x-originating-ip: [10.22.254.138] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8BIT MIME-Version: 1.0 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 672 Lines: 16 > You could alternatively use flush and make the worker code schedule the > work on a still online CPU in the domain instead of blindly rescheduling it > on the same CPU. We looked at that when you suggested flush. The problem is that we have already deleted the current cpu from the bitmask for the domain. So the worker code doesn't know which domain it is running on, so can't pick another. If we try to do the flush before dropping the cpu from the bitmask, then the worker code doesn't have any reason to pick a different CPU. Is there is some cheap "I'm running on a CPU that is in the process of going offline" test that we could make in the worker code? -Tony