From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753560AbbFUUXX (ORCPT ); Sun, 21 Jun 2015 16:23:23 -0400 Received: from mta-out1.inet.fi ([62.71.2.229]:42322 "EHLO johanna1.rokki.sonera.fi" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1752277AbbFUUXP (ORCPT ); Sun, 21 Jun 2015 16:23:15 -0400 RazorGate-KAS: Rate: 5 RazorGate-KAS: {RECEIVED: dynamic ip detected} RazorGate-KAS: Envelope from: RazorGate-KAS: Version: 5.5.3 RazorGate-KAS: LuaCore: 80 2014-11-10_18-01-23 260f8afb9361da3c7edfd3a8e3a4ca908191ad29 RazorGate-KAS: Method: none RazorGate-KAS: Lua profiles 69136 [Nov 12 2014] RazorGate-KAS: Status: not_detected Date: Sun, 21 Jun 2015 23:22:31 +0300 From: "Kirill A. Shutemov" To: Dave Hansen , Ingo Molnar Cc: Mel Gorman , Andrew Morton , Rik van Riel , Hugh Dickins , Minchan Kim , Andi Kleen , H Peter Anvin , Linux-MM , LKML , Linus Torvalds , Peter Zijlstra , Thomas Gleixner Subject: Re: [PATCH 0/3] TLB flush multiple pages per IPI v5 Message-ID: <20150621202231.GB6766@node.dhcp.inet.fi> References: <1433767854-24408-1-git-send-email-mgorman@suse.de> <20150608174551.GA27558@gmail.com> <20150609084739.GQ26425@suse.de> <20150609103231.GA11026@gmail.com> <20150609112055.GS26425@suse.de> <20150609124328.GA23066@gmail.com> <5577078B.2000503@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5577078B.2000503@intel.com> User-Agent: Mutt/1.5.23.1 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Jun 09, 2015 at 08:34:35AM -0700, Dave Hansen wrote: > On 06/09/2015 05:43 AM, Ingo Molnar wrote: > > +static char tlb_flush_target[PAGE_SIZE] __aligned(4096); > > +static void fn_flush_tlb_one(void) > > +{ > > + unsigned long addr = (unsigned long)&tlb_flush_target; > > + > > + tlb_flush_target[0]++; > > + __flush_tlb_one(addr); > > +} > > So we've got an increment of a variable in kernel memory (which is > almost surely in the L1), then we flush that memory location, and repeat > the increment. BTW, Ingo, have you disabled direct mapping of kernel memory with 2M/1G pages for the test? I'm just thinking if there is chance that the test shooting out 1G tlb entry. In this case we're measure wrong thing. -- Kirill A. Shutemov -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in Please read the FAQ at http://www.tux.org/lkml/