From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1750866AbdE1OLX (ORCPT ); Sun, 28 May 2017 10:11:23 -0400 Received: from mx1.redhat.com ([209.132.183.28]:44170 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750776AbdE1OLW (ORCPT ); Sun, 28 May 2017 10:11:22 -0400 DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 123A42D9FC1 Authentication-Results: ext-mx06.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx06.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=riel@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com 123A42D9FC1 Message-ID: <1495980680.29205.68.camel@redhat.com> Subject: Re: [x86/mm] e2a7dcce31: kernel_BUG_at_arch/x86/mm/tlb.c From: Rik van Riel To: Andy Lutomirski , kernel test robot , X86 ML Cc: Dave Hansen , Nadav Amit , Michal Hocko , Andrew Morton , Arjan van de Ven , LKML , LKP Date: Sun, 28 May 2017 10:11:20 -0400 In-Reply-To: References: <20170527133113.GA33229@inn.lkp.intel.com> Organization: Red Hat, Inc Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.30]); Sun, 28 May 2017 14:11:22 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sat, 2017-05-27 at 09:00 -0700, Andy Lutomirski wrote: > On Sat, May 27, 2017 at 6:31 AM, kernel test robot > wrote: > > > > FYI, we noticed the following commit: > > > > commit: e2a7dcce31f10bd7471b4245a6d1f2de344e7adf ("x86/mm: Rework > > lazy TLB to track the actual loaded mm") > > https://git.kernel.org/cgit/linux/kernel/git/luto/linux.git > > x86/tlbflush_cleanup > > Ugh, there's an unpleasant interaction between this patch and > intel_idle.  I suspect that the intel_idle code in question is either > wrong or pointless, It would be pointless if my "make lazy TLB mode even lazier" patch from last year had been applied. https://patchwork.kernel.org/patch/9307541/ I guess I'll go re-send that and investigate the intel_idle code in addition to that. From mboxrd@z Thu Jan 1 00:00:00 1970 Content-Type: multipart/mixed; boundary="===============1560941585782173127==" MIME-Version: 1.0 From: Rik van Riel To: lkp@lists.01.org Subject: Re: [x86/mm] e2a7dcce31: kernel_BUG_at_arch/x86/mm/tlb.c Date: Sun, 28 May 2017 10:11:20 -0400 Message-ID: <1495980680.29205.68.camel@redhat.com> In-Reply-To: List-Id: --===============1560941585782173127== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable On Sat, 2017-05-27 at 09:00 -0700, Andy Lutomirski wrote: > On Sat, May 27, 2017 at 6:31 AM, kernel test robot > wrote: > > = > > FYI, we noticed the following commit: > > = > > commit: e2a7dcce31f10bd7471b4245a6d1f2de344e7adf ("x86/mm: Rework > > lazy TLB to track the actual loaded mm") > > https://git.kernel.org/cgit/linux/kernel/git/luto/linux.git > > x86/tlbflush_cleanup > = > Ugh, there's an unpleasant interaction between this patch and > intel_idle.=C2=A0=C2=A0I suspect that the intel_idle code in question is = either > wrong or pointless, It would be pointless if my "make lazy TLB mode even lazier" patch from last year had been applied. https://patchwork.kernel.org/patch/9307541/ I guess I'll go re-send that and investigate the intel_idle code in addition to that. --===============1560941585782173127==--