From: Vlastimil Babka <vbabka@suse.cz>
To: Mel Gorman <mgorman@techsingularity.net>,
Andrew Morton <akpm@linux-foundation.org>
Cc: Linux-MM <linux-mm@kvack.org>,
Linux-FSDevel <linux-fsdevel@vger.kernel.org>,
LKML <linux-kernel@vger.kernel.org>, Jan Kara <jack@suse.cz>,
Andi Kleen <ak@linux.intel.com>,
Dave Hansen <dave.hansen@intel.com>,
Dave Chinner <david@fromorbit.com>
Subject: Re: [PATCH 8/8] mm: Remove __GFP_COLD
Date: Thu, 19 Oct 2017 15:18:14 +0200 [thread overview]
Message-ID: <a596669e-ea78-5aa3-a30f-0ae28786fd56@suse.cz> (raw)
In-Reply-To: <20171018075952.10627-9-mgorman@techsingularity.net>
On 10/18/2017 09:59 AM, Mel Gorman wrote:
> As the page free path makes no distinction between cache hot and cold
> pages, there is no real useful ordering of pages in the free list that
> allocation requests can take advantage of. Juding from the users of
> __GFP_COLD, it is likely that a number of them are the result of copying
> other sites instead of actually measuring the impact. Remove the
> __GFP_COLD parameter which simplifies a number of paths in the page
> allocator.
>
> This is potentially controversial but bear in mind that the size of the
> per-cpu pagelists versus modern cache sizes means that the whole per-cpu
> list can often fit in the L3 cache. Hence, there is only a potential benefit
> for microbenchmarks that alloc/free pages in a tight loop. It's even worse
> when THP is taken into account which has little or no chance of getting a
> cache-hot page as the per-cpu list is bypassed and the zeroing of multiple
> pages will thrash the cache anyway.
>
> The truncate microbenchmarks are not shown as this patch affects the
> allocation path and not the free path. A page fault microbenchmark was
> tested but it showed no sigificant difference which is not surprising given
> that the __GFP_COLD branches are a miniscule percentage of the fault path.
>
> Signed-off-by: Mel Gorman <mgorman@techsingularity.net>
Acked-by: Vlastimil Babka <vbabka@suse.cz>
WARNING: multiple messages have this Message-ID (diff)
From: Vlastimil Babka <vbabka@suse.cz>
To: Mel Gorman <mgorman@techsingularity.net>,
Andrew Morton <akpm@linux-foundation.org>
Cc: Linux-MM <linux-mm@kvack.org>,
Linux-FSDevel <linux-fsdevel@vger.kernel.org>,
LKML <linux-kernel@vger.kernel.org>, Jan Kara <jack@suse.cz>,
Andi Kleen <ak@linux.intel.com>,
Dave Hansen <dave.hansen@intel.com>,
Dave Chinner <david@fromorbit.com>
Subject: Re: [PATCH 8/8] mm: Remove __GFP_COLD
Date: Thu, 19 Oct 2017 15:18:14 +0200 [thread overview]
Message-ID: <a596669e-ea78-5aa3-a30f-0ae28786fd56@suse.cz> (raw)
In-Reply-To: <20171018075952.10627-9-mgorman@techsingularity.net>
On 10/18/2017 09:59 AM, Mel Gorman wrote:
> As the page free path makes no distinction between cache hot and cold
> pages, there is no real useful ordering of pages in the free list that
> allocation requests can take advantage of. Juding from the users of
> __GFP_COLD, it is likely that a number of them are the result of copying
> other sites instead of actually measuring the impact. Remove the
> __GFP_COLD parameter which simplifies a number of paths in the page
> allocator.
>
> This is potentially controversial but bear in mind that the size of the
> per-cpu pagelists versus modern cache sizes means that the whole per-cpu
> list can often fit in the L3 cache. Hence, there is only a potential benefit
> for microbenchmarks that alloc/free pages in a tight loop. It's even worse
> when THP is taken into account which has little or no chance of getting a
> cache-hot page as the per-cpu list is bypassed and the zeroing of multiple
> pages will thrash the cache anyway.
>
> The truncate microbenchmarks are not shown as this patch affects the
> allocation path and not the free path. A page fault microbenchmark was
> tested but it showed no sigificant difference which is not surprising given
> that the __GFP_COLD branches are a miniscule percentage of the fault path.
>
> Signed-off-by: Mel Gorman <mgorman@techsingularity.net>
Acked-by: Vlastimil Babka <vbabka@suse.cz>
--
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>
next prev parent reply other threads:[~2017-10-19 13:18 UTC|newest]
Thread overview: 47+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-10-18 7:59 [PATCH 0/8] Follow-up for speed up page cache truncation v2 Mel Gorman
2017-10-18 7:59 ` Mel Gorman
2017-10-18 7:59 ` [PATCH 1/8] mm, page_alloc: Enable/disable IRQs once when freeing a list of pages Mel Gorman
2017-10-18 7:59 ` Mel Gorman
2017-10-18 9:02 ` Vlastimil Babka
2017-10-18 9:02 ` Vlastimil Babka
2017-10-18 10:15 ` Mel Gorman
2017-10-18 10:15 ` Mel Gorman
2017-10-18 7:59 ` [PATCH 2/8] mm, truncate: Do not check mapping for every page being truncated Mel Gorman
2017-10-18 7:59 ` Mel Gorman
2017-10-19 8:11 ` Jan Kara
2017-10-19 8:11 ` Jan Kara
2017-10-18 7:59 ` [PATCH 3/8] mm, truncate: Remove all exceptional entries from pagevec under one lock Mel Gorman
2017-10-18 7:59 ` Mel Gorman
2017-10-18 7:59 ` [PATCH 4/8] mm: Only drain per-cpu pagevecs once per pagevec usage Mel Gorman
2017-10-18 7:59 ` Mel Gorman
2017-10-19 9:12 ` Vlastimil Babka
2017-10-19 9:12 ` Vlastimil Babka
2017-10-19 9:33 ` Mel Gorman
2017-10-19 9:33 ` Mel Gorman
2017-10-19 13:21 ` Vlastimil Babka
2017-10-19 13:21 ` Vlastimil Babka
2017-10-18 7:59 ` [PATCH 5/8] mm, pagevec: Remove cold parameter for pagevecs Mel Gorman
2017-10-18 7:59 ` Mel Gorman
2017-10-19 9:24 ` Vlastimil Babka
2017-10-19 9:24 ` Vlastimil Babka
2017-10-18 7:59 ` [PATCH 6/8] mm: Remove cold parameter for release_pages Mel Gorman
2017-10-18 7:59 ` Mel Gorman
2017-10-19 9:26 ` Vlastimil Babka
2017-10-19 9:26 ` Vlastimil Babka
2017-10-18 7:59 ` [PATCH 7/8] mm, Remove cold parameter from free_hot_cold_page* Mel Gorman
2017-10-18 7:59 ` Mel Gorman
2017-10-19 13:12 ` Vlastimil Babka
2017-10-19 13:12 ` Vlastimil Babka
2017-10-19 15:43 ` Mel Gorman
2017-10-19 15:43 ` Mel Gorman
2017-10-18 7:59 ` [PATCH 8/8] mm: Remove __GFP_COLD Mel Gorman
2017-10-18 7:59 ` Mel Gorman
2017-10-19 13:18 ` Vlastimil Babka [this message]
2017-10-19 13:18 ` Vlastimil Babka
2017-10-19 13:42 ` Vlastimil Babka
2017-10-19 13:42 ` Vlastimil Babka
2017-10-19 13:42 ` Vlastimil Babka
2017-10-19 14:32 ` Mel Gorman
2017-10-19 14:32 ` Mel Gorman
-- strict thread matches above, loose matches on Subject: below --
2017-10-12 9:30 [PATCH 0/8] Follow-up for speed up page cache truncation Mel Gorman
2017-10-12 9:31 ` [PATCH 8/8] mm: Remove __GFP_COLD Mel Gorman
2017-10-12 9:31 ` 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=a596669e-ea78-5aa3-a30f-0ae28786fd56@suse.cz \
--to=vbabka@suse.cz \
--cc=ak@linux.intel.com \
--cc=akpm@linux-foundation.org \
--cc=dave.hansen@intel.com \
--cc=david@fromorbit.com \
--cc=jack@suse.cz \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mgorman@techsingularity.net \
/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.