From: Rik van Riel <riel@redhat.com>
To: Dave Hansen <dave@sr71.net>, x86@kernel.org
Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org,
akpm@linux-foundation.org, kirill.shutemov@linux.intel.com,
mgorman@suse.de, ak@linux.intel.com, alex.shi@linaro.org,
dave.hansen@linux.intel.com
Subject: Re: [PATCH 2/6] x86: mm: rip out complicated, out-of-date, buggy TLB flushing
Date: Tue, 22 Apr 2014 12:54:43 -0400 [thread overview]
Message-ID: <53569ED3.2080206@redhat.com> (raw)
In-Reply-To: <20140421182421.DFAAD16A@viggo.jf.intel.com>
On 04/21/2014 02:24 PM, Dave Hansen wrote:
> From: Dave Hansen <dave.hansen@linux.intel.com>
>
> I think the flush_tlb_mm_range() code that tries to tune the
> flush sizes based on the CPU needs to get ripped out for
> several reasons:
>
> 1. It is obviously buggy. It uses mm->total_vm to judge the
> task's footprint in the TLB. It should certainly be using
> some measure of RSS, *NOT* ->total_vm since only resident
> memory can populate the TLB.
> 2. Haswell, and several other CPUs are missing from the
> intel_tlb_flushall_shift_set() function. Thus, it has been
> demonstrated to bitrot quickly in practice.
> 3. It is plain wrong in my vm:
> [ 0.037444] Last level iTLB entries: 4KB 0, 2MB 0, 4MB 0
> [ 0.037444] Last level dTLB entries: 4KB 0, 2MB 0, 4MB 0
> [ 0.037444] tlb_flushall_shift: 6
> Which leads to it to never use invlpg.
> 4. The assumptions about TLB refill costs are wrong:
> http://lkml.kernel.org/r/1337782555-8088-3-git-send-email-alex.shi@intel.com
> (more on this in later patches)
> 5. I can not reproduce the original data: https://lkml.org/lkml/2012/5/17/59
> I believe the sample times were too short. Running the
> benchmark in a loop yields times that vary quite a bit.
>
> Note that this leaves us with a static ceiling of 1 page. This
> is a conservative, dumb setting, and will be revised in a later
> patch.
>
> Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com>
Acked-by: Rik van Riel <riel@redhat.com>
--
All rights reversed
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
WARNING: multiple messages have this Message-ID (diff)
From: Rik van Riel <riel@redhat.com>
To: Dave Hansen <dave@sr71.net>, x86@kernel.org
Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org,
akpm@linux-foundation.org, kirill.shutemov@linux.intel.com,
mgorman@suse.de, ak@linux.intel.com, alex.shi@linaro.org,
dave.hansen@linux.intel.com
Subject: Re: [PATCH 2/6] x86: mm: rip out complicated, out-of-date, buggy TLB flushing
Date: Tue, 22 Apr 2014 12:54:43 -0400 [thread overview]
Message-ID: <53569ED3.2080206@redhat.com> (raw)
In-Reply-To: <20140421182421.DFAAD16A@viggo.jf.intel.com>
On 04/21/2014 02:24 PM, Dave Hansen wrote:
> From: Dave Hansen <dave.hansen@linux.intel.com>
>
> I think the flush_tlb_mm_range() code that tries to tune the
> flush sizes based on the CPU needs to get ripped out for
> several reasons:
>
> 1. It is obviously buggy. It uses mm->total_vm to judge the
> task's footprint in the TLB. It should certainly be using
> some measure of RSS, *NOT* ->total_vm since only resident
> memory can populate the TLB.
> 2. Haswell, and several other CPUs are missing from the
> intel_tlb_flushall_shift_set() function. Thus, it has been
> demonstrated to bitrot quickly in practice.
> 3. It is plain wrong in my vm:
> [ 0.037444] Last level iTLB entries: 4KB 0, 2MB 0, 4MB 0
> [ 0.037444] Last level dTLB entries: 4KB 0, 2MB 0, 4MB 0
> [ 0.037444] tlb_flushall_shift: 6
> Which leads to it to never use invlpg.
> 4. The assumptions about TLB refill costs are wrong:
> http://lkml.kernel.org/r/1337782555-8088-3-git-send-email-alex.shi@intel.com
> (more on this in later patches)
> 5. I can not reproduce the original data: https://lkml.org/lkml/2012/5/17/59
> I believe the sample times were too short. Running the
> benchmark in a loop yields times that vary quite a bit.
>
> Note that this leaves us with a static ceiling of 1 page. This
> is a conservative, dumb setting, and will be revised in a later
> patch.
>
> Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com>
Acked-by: Rik van Riel <riel@redhat.com>
--
All rights reversed
next prev parent reply other threads:[~2014-04-22 16:54 UTC|newest]
Thread overview: 56+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-04-21 18:24 [PATCH 0/6] x86: rework tlb range flushing code Dave Hansen
2014-04-21 18:24 ` Dave Hansen
2014-04-21 18:24 ` [PATCH 1/6] x86: mm: clean up tlb " Dave Hansen
2014-04-21 18:24 ` Dave Hansen
2014-04-22 16:53 ` Rik van Riel
2014-04-22 16:53 ` Rik van Riel
2014-04-24 8:33 ` Mel Gorman
2014-04-24 8:33 ` Mel Gorman
2014-04-21 18:24 ` [PATCH 2/6] x86: mm: rip out complicated, out-of-date, buggy TLB flushing Dave Hansen
2014-04-21 18:24 ` Dave Hansen
2014-04-22 16:54 ` Rik van Riel [this message]
2014-04-22 16:54 ` Rik van Riel
2014-04-24 8:45 ` Mel Gorman
2014-04-24 8:45 ` Mel Gorman
2014-04-24 16:58 ` Dave Hansen
2014-04-24 16:58 ` Dave Hansen
2014-04-24 18:00 ` Mel Gorman
2014-04-24 18:00 ` Mel Gorman
2014-04-25 21:39 ` Dave Hansen
2014-04-25 21:39 ` Dave Hansen
2014-04-21 18:24 ` [PATCH 3/6] x86: mm: fix missed global TLB flush stat Dave Hansen
2014-04-21 18:24 ` Dave Hansen
2014-04-22 17:15 ` Rik van Riel
2014-04-22 17:15 ` Rik van Riel
2014-04-24 8:49 ` Mel Gorman
2014-04-24 8:49 ` Mel Gorman
2014-04-21 18:24 ` [PATCH 4/6] x86: mm: trace tlb flushes Dave Hansen
2014-04-21 18:24 ` Dave Hansen
2014-04-22 21:19 ` Rik van Riel
2014-04-22 21:19 ` Rik van Riel
2014-04-24 10:14 ` Mel Gorman
2014-04-24 10:14 ` Mel Gorman
2014-04-24 20:42 ` Dave Hansen
2014-04-24 20:42 ` Dave Hansen
2014-04-21 18:24 ` [PATCH 5/6] x86: mm: new tunable for single vs full TLB flush Dave Hansen
2014-04-21 18:24 ` Dave Hansen
2014-04-22 21:31 ` Rik van Riel
2014-04-22 21:31 ` Rik van Riel
2014-04-24 10:37 ` Mel Gorman
2014-04-24 10:37 ` Mel Gorman
2014-04-24 17:25 ` Dave Hansen
2014-04-24 17:25 ` Dave Hansen
2014-04-24 17:53 ` Rik van Riel
2014-04-24 17:53 ` Rik van Riel
2014-04-24 22:03 ` Dave Hansen
2014-04-24 22:03 ` Dave Hansen
2014-07-07 17:43 ` Dave Hansen
2014-07-07 17:43 ` Dave Hansen
2014-07-08 0:43 ` Alex Shi
2014-07-08 0:43 ` Alex Shi
2014-04-21 18:24 ` [PATCH 6/6] x86: mm: set TLB flush tunable to sane value (33) Dave Hansen
2014-04-21 18:24 ` Dave Hansen
2014-04-22 21:33 ` Rik van Riel
2014-04-22 21:33 ` Rik van Riel
2014-04-24 10:46 ` Mel Gorman
2014-04-24 10:46 ` Mel Gorman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=53569ED3.2080206@redhat.com \
--to=riel@redhat.com \
--cc=ak@linux.intel.com \
--cc=akpm@linux-foundation.org \
--cc=alex.shi@linaro.org \
--cc=dave.hansen@linux.intel.com \
--cc=dave@sr71.net \
--cc=kirill.shutemov@linux.intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mgorman@suse.de \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.