Received: by 10.223.185.116 with SMTP id b49csp3212979wrg; Mon, 5 Mar 2018 16:41:10 -0800 (PST) X-Google-Smtp-Source: AG47ELt6UitjHd+mtaPY8L86EqrIySC3IGf39joqdLo+6Ifmv6D6E9L46FKk9hiLowjtxe+WRDAj X-Received: by 2002:a17:902:5a0d:: with SMTP id q13-v6mr14820897pli.152.1520296870477; Mon, 05 Mar 2018 16:41:10 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1520296870; cv=none; d=google.com; s=arc-20160816; b=qeV1baRUdy5nCoxd7cnl7v8lium6RN1YIHkumjO+QYRwvH64jMlxcWf7rLre3NQcfj lB2jYTVcD8oKlC5Fr+wYMlWL2HW7YFRv3CCBpM7TpG6EH0yJ2N/FXXPvRPbYH/GVOUFm j9X4NPjfGVmNiTSUnkZcFdRd0l2dVVJuLUhvW4+9pR8/fVgeu2WGUQQ2Z9TNjPbwUMZf GCNkjlkNqcHtGfE2CcsPYUDvhJShT/E1SSqqsdKvrngVAV6gzNQakgrXB/IQJ5QN7IQo /4tB8gA++ncC8xmtMwoW6uofX41thQNbe/GgayFJVAEXpdhjFRrZSsDaRi00mhuprJeB OGlA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:references:in-reply-to:message-id:date :subject:to:from:dkim-signature:arc-authentication-results; bh=lthWPhASUsytPLDUOvPxBs0Eic4fJmKrdLabUUi49ls=; b=JQlT7cqa/pdcxuIPuHTfhKQmIuBucQJVh8qgLsDMY36FCbdpj/wIoTjF+5LgkuWnxe 9/E3p9FEGV3awZ/Oe4d6QADrRKiu0gh8IzRgt5wdQIFWESZmOFPMeFWWy8Cajzz/b4PE 3aeAGEqdE+qG19T0TklwlGjuLf/348zwwcWxPCbW5xGwB84Y1TqYWm0SyT+F7XkcQoyJ ra5sOBlOOxO/u2lYp5f5PWVANPAymTC2cVgOa72uShqJHlbiyxT9IUMYrQEn/o6Y3+0u 4bReXKEgtpaX8Dbu50vCUCjchQgqkxkB/k1zVKJxCc5acHELIxAKKDcsf77zJIcnULeo qnag== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@oracle.com header.s=corp-2017-10-26 header.b=FlR7EtO6; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=oracle.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id r26si10985151pfi.378.2018.03.05.16.40.56; Mon, 05 Mar 2018 16:41:10 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@oracle.com header.s=corp-2017-10-26 header.b=FlR7EtO6; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=oracle.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933051AbeCFA0S (ORCPT + 99 others); Mon, 5 Mar 2018 19:26:18 -0500 Received: from aserp2120.oracle.com ([141.146.126.78]:56164 "EHLO aserp2120.oracle.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932961AbeCFA0N (ORCPT ); Mon, 5 Mar 2018 19:26:13 -0500 Received: from pps.filterd (aserp2120.oracle.com [127.0.0.1]) by aserp2120.oracle.com (8.16.0.22/8.16.0.22) with SMTP id w260LVar034894; Tue, 6 Mar 2018 00:26:10 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=from : to : subject : date : message-id : in-reply-to : references; s=corp-2017-10-26; bh=lthWPhASUsytPLDUOvPxBs0Eic4fJmKrdLabUUi49ls=; b=FlR7EtO66crupiNLm8icsqLDZ0pBkGXzHftOk321g6o1Bz8h81TxhXjv0fThC+Bl2XZ1 pGSiHyX2k4grz5atnZT4EjyNrSEIhKLiTVP/GpmzwZSUttuBhCYG2VhGLlTyQX4tS3Ms xILiNfWFFdG2fOWbiZ3T4DHoZ5dhp41IW1TaXhaFrxaB4KjNLlSA012XSwEe343FzcJO sf0ubucWTxjTgJ2J89SZIH1nJVUY6mxquKGs6pY194sU2l0iyfT+QqOIWAHW+2Oiy21C cUI56Ov044Q5ISzfdx4xXTuPuN0ZD3DSToWem2J3TTg5VE+WeO3TeBdasr4gAlEVFW+y IQ== Received: from userv0022.oracle.com (userv0022.oracle.com [156.151.31.74]) by aserp2120.oracle.com with ESMTP id 2ghe3kgg34-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 06 Mar 2018 00:26:09 +0000 Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by userv0022.oracle.com (8.14.4/8.14.4) with ESMTP id w260Q9IP010813 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Tue, 6 Mar 2018 00:26:09 GMT Received: from abhmp0008.oracle.com (abhmp0008.oracle.com [141.146.116.14]) by userv0121.oracle.com (8.14.4/8.13.8) with ESMTP id w260Q8Fc029046; Tue, 6 Mar 2018 00:26:08 GMT Received: from localhost.localdomain (/98.216.35.41) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 05 Mar 2018 16:26:08 -0800 From: Pavel Tatashin To: steven.sistare@oracle.com, daniel.m.jordan@oracle.com, linux-kernel@vger.kernel.org, Alexander.Levin@microsoft.com, dan.j.williams@intel.com, sathyanarayanan.kuppuswamy@intel.com, pankaj.laxminarayan.bharadiya@intel.com, akuster@mvista.com, cminyard@mvista.com, pasha.tatashin@oracle.com, gregkh@linuxfoundation.org, stable@vger.kernel.org Subject: [PATCH 4.1 12/65] x86/irq: Do not substract irq_tlb_count from irq_call_count Date: Mon, 5 Mar 2018 19:24:45 -0500 Message-Id: <20180306002538.1761-13-pasha.tatashin@oracle.com> X-Mailer: git-send-email 2.16.2 In-Reply-To: <20180306002538.1761-1-pasha.tatashin@oracle.com> References: <20180306002538.1761-1-pasha.tatashin@oracle.com> X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=8823 signatures=668683 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1803060003 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Aaron Lu commit 82ba4faca1bffad429f15c90c980ffd010366c25 upstream. Since commit: 52aec3308db8 ("x86/tlb: replace INVALIDATE_TLB_VECTOR by CALL_FUNCTION_VECTOR") the TLB remote shootdown is done through call function vector. That commit didn't take care of irq_tlb_count, which a later commit: fd0f5869724f ("x86: Distinguish TLB shootdown interrupts from other functions call interrupts") ... tried to fix. The fix assumes every increase of irq_tlb_count has a corresponding increase of irq_call_count. So the irq_call_count is always bigger than irq_tlb_count and we could substract irq_tlb_count from irq_call_count. Unfortunately this is not true for the smp_call_function_single() case. The IPI is only sent if the target CPU's call_single_queue is empty when adding a csd into it in generic_exec_single. That means if two threads are both adding flush tlb csds to the same CPU's call_single_queue, only one IPI is sent. In other words, the irq_call_count is incremented by 1 but irq_tlb_count is incremented by 2. Over time, irq_tlb_count will be bigger than irq_call_count and the substract will produce a very large irq_call_count value due to overflow. Considering that: 1) it's not worth to send more IPIs for the sake of accurate counting of irq_call_count in generic_exec_single(); 2) it's not easy to tell if the call function interrupt is for TLB shootdown in __smp_call_function_single_interrupt(). Not to exclude TLB shootdown from call function count seems to be the simplest fix and this patch just does that. This bug was found by LKP's cyclic performance regression tracking recently with the vm-scalability test suite. I have bisected to commit: 3dec0ba0be6a ("mm/rmap: share the i_mmap_rwsem") This commit didn't do anything wrong but revealed the irq_call_count problem. IIUC, the commit makes rwc->remap_one in rmap_walk_file concurrent with multiple threads. When remap_one is try_to_unmap_one(), then multiple threads could queue flush TLB to the same CPU but only one IPI will be sent. Since the commit was added in Linux v3.19, the counting problem only shows up from v3.19 onwards. Signed-off-by: Aaron Lu Cc: Alex Shi Cc: Andy Lutomirski Cc: Borislav Petkov Cc: Brian Gerst Cc: Davidlohr Bueso Cc: Denys Vlasenko Cc: H. Peter Anvin Cc: Huang Ying Cc: Josh Poimboeuf Cc: Linus Torvalds Cc: Peter Zijlstra Cc: Thomas Gleixner Cc: Tomoki Sekiyama Link: http://lkml.kernel.org/r/20160811074430.GA18163@aaronlu.sh.intel.com Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman (cherry picked from commit 3b9d9ec0d8261bb9b12f858e66f0c84cd2a6a3bb) Signed-off-by: Pavel Tatashin --- arch/x86/include/asm/hardirq.h | 4 ---- arch/x86/kernel/irq.c | 3 +-- 2 files changed, 1 insertion(+), 6 deletions(-) diff --git a/arch/x86/include/asm/hardirq.h b/arch/x86/include/asm/hardirq.h index 0f5fb6b6567e..ebaf64d0a785 100644 --- a/arch/x86/include/asm/hardirq.h +++ b/arch/x86/include/asm/hardirq.h @@ -21,10 +21,6 @@ typedef struct { #ifdef CONFIG_SMP unsigned int irq_resched_count; unsigned int irq_call_count; - /* - * irq_tlb_count is double-counted in irq_call_count, so it must be - * subtracted from irq_call_count when displaying irq_call_count - */ unsigned int irq_tlb_count; #endif #ifdef CONFIG_X86_THERMAL_VECTOR diff --git a/arch/x86/kernel/irq.c b/arch/x86/kernel/irq.c index e5952c225532..b6460c5a9cab 100644 --- a/arch/x86/kernel/irq.c +++ b/arch/x86/kernel/irq.c @@ -96,8 +96,7 @@ int arch_show_interrupts(struct seq_file *p, int prec) seq_puts(p, " Rescheduling interrupts\n"); seq_printf(p, "%*s: ", prec, "CAL"); for_each_online_cpu(j) - seq_printf(p, "%10u ", irq_stats(j)->irq_call_count - - irq_stats(j)->irq_tlb_count); + seq_printf(p, "%10u ", irq_stats(j)->irq_call_count); seq_puts(p, " Function call interrupts\n"); seq_printf(p, "%*s: ", prec, "TLB"); for_each_online_cpu(j) -- 2.16.2