From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751646AbdIFRqU (ORCPT ); Wed, 6 Sep 2017 13:46:20 -0400 Received: from mail-oi0-f54.google.com ([209.85.218.54]:33727 "EHLO mail-oi0-f54.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750789AbdIFRqT (ORCPT ); Wed, 6 Sep 2017 13:46:19 -0400 X-Google-Smtp-Source: ADKCNb6z3ThLV9FFGgAfGVvf3k+h3tIJ9/p4A3BkK+Go2+Covskt6pbXq43deUqTLFHCvTHK4m7V20ccHG3Y+lp5ZYc= MIME-Version: 1.0 In-Reply-To: <20170906061545.GA20519@lst.de> References: <20170906041337.GC23250@localhost.localdomain> <20170906061545.GA20519@lst.de> From: Dan Williams Date: Wed, 6 Sep 2017 10:46:17 -0700 Message-ID: Subject: Re: [PATCH 4/4][RFC v2] x86/apic: Spread the vectors by choosing the idlest CPU To: Christoph Hellwig Cc: Yu Chen , Thomas Gleixner , X86 ML , Ingo Molnar , "H. Peter Anvin" , Rui Zhang , LKML , "Rafael J. Wysocki" , Len Brown , Peter Zijlstra Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Sep 5, 2017 at 11:15 PM, Christoph Hellwig wrote: > On Wed, Sep 06, 2017 at 12:13:38PM +0800, Yu Chen wrote: >> I agree, the driver could be rewritten, but it might take some time, so >> meanwhile I'm looking at also other possible optimization. > > Which driver are we talking about anyway? Let's start looking at it > and fix the issue there. As far as I understand, it's already fixed there: commit 7c9ae7f053e9e896c24fd23595ba369a5fe322e1 Author: Carolyn Wyborny Date: Tue Jun 20 15:16:53 2017 -0700 i40e: Fix for trace found with S4 state This patch fixes a problem found in systems when entering S4 state. This patch fixes the problem by ensuring that the misc vector's IRQ is disabled as well. Without this patch a stack trace can be seen upon entering S4 state. However this seems like something that should be handled generically in the irq-core especially since commit c5cb83bb337c "genirq/cpuhotplug: Handle managed IRQs on CPU hotplug" was headed in that direction. It's otherwise non-obvious when a driver needs to release and re-acquire interrupts or be reworked to use managed interrupts.