Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753904AbbGWQww (ORCPT ); Thu, 23 Jul 2015 12:52:52 -0400 Received: from mga11.intel.com ([192.55.52.93]:59140 "EHLO mga11.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752577AbbGWQwt (ORCPT ); Thu, 23 Jul 2015 12:52:49 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.15,532,1432623600"; d="scan'208";a="769957969" Message-ID: <55B11BE1.3070903@intel.com> Date: Thu, 23 Jul 2015 09:52:49 -0700 From: Dave Hansen User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Andrea Arcangeli CC: Catalin Marinas , David Rientjes , linux-mm , Linux Kernel Mailing List , Andrew Morton Subject: Re: [PATCH] mm: Flush the TLB for a single address in a huge page References: <1437585214-22481-1-git-send-email-catalin.marinas@arm.com> <55B021B1.5020409@intel.com> <20150723104938.GA27052@e104818-lin.cambridge.arm.com> <20150723141303.GB23799@redhat.com> <55B0FD14.8050501@intel.com> <20150723155801.GC23799@redhat.com> In-Reply-To: <20150723155801.GC23799@redhat.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2142 Lines: 46 On 07/23/2015 08:58 AM, Andrea Arcangeli wrote: > You wrote the patch that uses the tlb_single_page_flush_ceiling, so if > the above discussion would be relevant with regard to flush_tlb_page, > are you implying that the above optimization in the kernel, should > also be removed? When I put that in, my goal was to bring consistency to how we handled things without regressing anything. I was never able to measure any nice macro-level benefits to a particular flush behavior. We can also now just easily disable the ranged flushes if we want to, or leave them in place for small flushes only. > When these flush_tlb_range optimizations were introduced, it was > measured with benchmark that they helped IIRC. If it's not true > anymore with latest CPU I don't know but there should be at least a > subset of those CPUs where this helps. So I doubt it should be removed > for all CPUs out there. I tried to reproduce the results and had a difficult time doing so. > The tlb_single_page_flush_ceiling optimization has nothing to do with > 2MB pages. But if that is still valid (or if it has ever been valid > for older CPUs), why is flush_tlb_page not a valid optimization at > least for those older CPUS? Why is it worth doing single invalidates > on 4k pages and not on 2MB pages? I haven't seen any solid evidence that we should do it for one and not the other. > It surely was helpful to do invlpg invalidated on 4k pages, up to 33 > in a row, with x86 CPUs as you wrote the code quoted above to do > that, and it is still in the current kernel. So why are 2MB pages > different? They were originally different because the work that introduced 'invlpg' didn't see a benefit from using 'invlpg' on 2M pages. I didn't reevaluate it when I hacked on the code and just left it as it was. It would be great if someone would go and collect some recent data on using 'invlpg' on 2M pages! -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/