From: Dave Hansen <dave@sr71.net>
To: Mel Gorman <mgorman@suse.de>
Cc: x86@kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org,
akpm@linux-foundation.org, kirill.shutemov@linux.intel.com,
ak@linux.intel.com, riel@redhat.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: Fri, 25 Apr 2014 14:39:57 -0700 [thread overview]
Message-ID: <535AD62D.20509@sr71.net> (raw)
In-Reply-To: <20140424084552.GQ23991@suse.de>
On 04/24/2014 01:45 AM, Mel Gorman wrote:
>> > +/*
>> > + * See Documentation/x86/tlb.txt for details. We choose 33
>> > + * because it is large enough to cover the vast majority (at
>> > + * least 95%) of allocations, and is small enough that we are
>> > + * confident it will not cause too much overhead. Each single
>> > + * flush is about 100 cycles, so this caps the maximum overhead
>> > + * at _about_ 3,000 cycles.
>> > + */
>> > +/* in units of pages */
>> > +unsigned long tlb_single_page_flush_ceiling = 1;
>> > +
> This comment is premature. The documentation file does not exist yet and
> 33 means nothing yet. Out of curiousity though, how confident are you
> that a TLB flush is generally 100 cycles across different generations
> and manufacturers of CPUs? I'm not suggesting you change it or auto-tune
> it, am just curious.
First of all, I changed the units here at some point, and I screwed up
the comments. I meant 100 nanoseconds, *not* cycles.
For the sake of completeness, here are the data on a Westmere CPU. I'm
not _quite_ sure why the <=5 pages cases are so slow per-page compared
to when we're flushing larger numbers of pages. (I also only printed
out the flush sizes with >100 samples):
The overall average was 151ns, and for 6 pages and up it was 107ns.
1 1560658 279861777 avg/page: 179
2 179981 85329139 avg/page: 237
3 99797 146972011 avg/page: 490
4 161470 133072233 avg/page: 206
5 44150 42142670 avg/page: 190
6 17364 12063833 avg/page: 115
7 12325 9899412 avg/page: 114
8 4202 3838077 avg/page: 114
9 811 990320 avg/page: 135
10 4448 4955283 avg/page: 111
11 69051 86723229 avg/page: 114
12 465 642204 avg/page: 115
13 157 226814 avg/page: 111
16 781 1741461 avg/page: 139
17 1506 2778201 avg/page: 108
18 110 211216 avg/page: 106
19 13322 27941893 avg/page: 110
21 1828 4092988 avg/page: 106
24 1566 4057605 avg/page: 107
25 246 646463 avg/page: 105
29 411 1275101 avg/page: 106
33 3191 11775818 avg/page: 111
52 3096 17297873 avg/page: 107
65 2244 15349445 avg/page: 105
129 2278 33246120 avg/page: 113
240 12181 305529055 avg/page: 104
--
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: Dave Hansen <dave@sr71.net>
To: Mel Gorman <mgorman@suse.de>
Cc: x86@kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org,
akpm@linux-foundation.org, kirill.shutemov@linux.intel.com,
ak@linux.intel.com, riel@redhat.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: Fri, 25 Apr 2014 14:39:57 -0700 [thread overview]
Message-ID: <535AD62D.20509@sr71.net> (raw)
In-Reply-To: <20140424084552.GQ23991@suse.de>
On 04/24/2014 01:45 AM, Mel Gorman wrote:
>> > +/*
>> > + * See Documentation/x86/tlb.txt for details. We choose 33
>> > + * because it is large enough to cover the vast majority (at
>> > + * least 95%) of allocations, and is small enough that we are
>> > + * confident it will not cause too much overhead. Each single
>> > + * flush is about 100 cycles, so this caps the maximum overhead
>> > + * at _about_ 3,000 cycles.
>> > + */
>> > +/* in units of pages */
>> > +unsigned long tlb_single_page_flush_ceiling = 1;
>> > +
> This comment is premature. The documentation file does not exist yet and
> 33 means nothing yet. Out of curiousity though, how confident are you
> that a TLB flush is generally 100 cycles across different generations
> and manufacturers of CPUs? I'm not suggesting you change it or auto-tune
> it, am just curious.
First of all, I changed the units here at some point, and I screwed up
the comments. I meant 100 nanoseconds, *not* cycles.
For the sake of completeness, here are the data on a Westmere CPU. I'm
not _quite_ sure why the <=5 pages cases are so slow per-page compared
to when we're flushing larger numbers of pages. (I also only printed
out the flush sizes with >100 samples):
The overall average was 151ns, and for 6 pages and up it was 107ns.
1 1560658 279861777 avg/page: 179
2 179981 85329139 avg/page: 237
3 99797 146972011 avg/page: 490
4 161470 133072233 avg/page: 206
5 44150 42142670 avg/page: 190
6 17364 12063833 avg/page: 115
7 12325 9899412 avg/page: 114
8 4202 3838077 avg/page: 114
9 811 990320 avg/page: 135
10 4448 4955283 avg/page: 111
11 69051 86723229 avg/page: 114
12 465 642204 avg/page: 115
13 157 226814 avg/page: 111
16 781 1741461 avg/page: 139
17 1506 2778201 avg/page: 108
18 110 211216 avg/page: 106
19 13322 27941893 avg/page: 110
21 1828 4092988 avg/page: 106
24 1566 4057605 avg/page: 107
25 246 646463 avg/page: 105
29 411 1275101 avg/page: 106
33 3191 11775818 avg/page: 111
52 3096 17297873 avg/page: 107
65 2244 15349445 avg/page: 105
129 2278 33246120 avg/page: 113
240 12181 305529055 avg/page: 104
next prev parent reply other threads:[~2014-04-25 21:40 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
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 [this message]
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=535AD62D.20509@sr71.net \
--to=dave@sr71.net \
--cc=ak@linux.intel.com \
--cc=akpm@linux-foundation.org \
--cc=alex.shi@linaro.org \
--cc=dave.hansen@linux.intel.com \
--cc=kirill.shutemov@linux.intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mgorman@suse.de \
--cc=riel@redhat.com \
--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.