From: Dave Hansen <dave.hansen@intel.com>
To: Andi Kleen <andi@firstfloor.org>, Mel Gorman <mgorman@suse.de>
Cc: Linux-MM <linux-mm@kvack.org>,
Linux-FSDevel <linux-fsdevel@vger.kernel.org>
Subject: Re: [PATCH 01/16] mm: Disable zone_reclaim_mode by default
Date: Fri, 18 Apr 2014 14:15:31 -0700 [thread overview]
Message-ID: <535195F3.8040009@intel.com> (raw)
In-Reply-To: <87tx9q35x7.fsf@tassilo.jf.intel.com>
On 04/18/2014 10:26 AM, Andi Kleen wrote:
> Mel Gorman <mgorman@suse.de> writes:
>> Favour the common case and disable it by default. Users that are
>> sophisticated enough to know they need zone_reclaim_mode will detect it.
>
> While I'm not totally against this change, it will destroy many
> carefully tuned configurations as the default NUMA behavior may be completely
> different now. So it seems like a big hammer, and it's not even clear
> what problem you're exactly solving here.
I'm not 100% sure what the common case _is_. Folks who want good NUMA
affinity are happy now and are happy by default. Folks who want to fill
memory with page cache are mad and mad by default, and they're the ones
complaining. It's hard to count the happy ones. :)
But, on the other hand, the current situation is easy to debug. Someone
complains that they have too much free memory, and it ends up being
pretty easy to solve just looking at statistics, and things go horribly
wrong quickly. If we apply this patch, it's much less obvious when
things are going wrong, and we have no statistics to help. We'll need
to get folks running more things like numatop:
https://01.org/numatop
That said, as a recipient of angry calls from customers who don't like
zone_reclaim_mode, I _do_ think this is the path we should take at the
moment. Maybe we'll be reverting it in a few years once all of our
customers are angry about lack of NUMA locality.
Acked-by: Dave Hansen <dave.hansen@linux.intel.com>
--
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:[~2014-04-18 21:15 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-04-18 14:50 [PATCH 00/16] Misc page alloc, shmem and mark_page_accessed optimisations Mel Gorman
2014-04-18 14:50 ` [PATCH 01/16] mm: Disable zone_reclaim_mode by default Mel Gorman
2014-04-18 17:26 ` Andi Kleen
2014-04-18 21:15 ` Dave Hansen [this message]
2014-04-18 14:50 ` [PATCH 02/16] mm: page_alloc: Do not cache reclaim distances Mel Gorman
2014-04-18 14:50 ` [PATCH 03/16] mm: page_alloc: Do not update zlc unless the zlc is active Mel Gorman
2014-04-18 17:52 ` Johannes Weiner
2014-04-18 14:50 ` [PATCH 04/16] mm: page_alloc: Do not treat a zone that cannot be used for dirty pages as "full" Mel Gorman
2014-04-18 17:52 ` Johannes Weiner
2014-04-18 14:50 ` [PATCH 05/16] mm: page_alloc: Use jump labels to avoid checking number_of_cpusets Mel Gorman
2014-04-18 14:50 ` [PATCH 06/16] mm: page_alloc: Calculate classzone_idx once from the zonelist ref Mel Gorman
2014-04-18 18:03 ` Johannes Weiner
2014-04-19 11:18 ` Mel Gorman
2014-04-18 14:50 ` [PATCH 07/16] mm: page_alloc: Only check the zone id check if pages are buddies Mel Gorman
2014-04-18 18:05 ` Johannes Weiner
2014-04-18 14:50 ` [PATCH 08/16] mm: page_alloc: Only check the alloc flags and gfp_mask for dirty once Mel Gorman
2014-04-18 18:08 ` Johannes Weiner
2014-04-19 11:19 ` Mel Gorman
2014-04-18 14:50 ` [PATCH 09/16] mm: page_alloc: Take the ALLOC_NO_WATERMARK check out of the fast path Mel Gorman
2014-04-18 18:10 ` Johannes Weiner
2014-04-18 14:50 ` [PATCH 10/16] mm: page_alloc: Use word-based accesses for get/set pageblock bitmaps Mel Gorman
2014-04-18 17:16 ` Vlastimil Babka
2014-04-18 14:50 ` [PATCH 11/16] mm: page_alloc: Reduce number of times page_to_pfn is called Mel Gorman
2014-04-18 14:50 ` [PATCH 12/16] mm: shmem: Avoid atomic operation during shmem_getpage_gfp Mel Gorman
2014-04-18 18:13 ` Johannes Weiner
2014-04-18 14:50 ` [PATCH 13/16] mm: Do not use atomic operations when releasing pages Mel Gorman
2014-04-18 14:50 ` [PATCH 14/16] mm: Do not use unnecessary atomic operations when adding pages to the LRU Mel Gorman
2014-04-18 14:50 ` [PATCH 15/16] mm: Non-atomically mark page accessed in write_begin where possible Mel Gorman
2014-04-18 14:50 ` [PATCH 16/16] mm: filemap: Prefetch page->flags if !PageUptodate Mel Gorman
2014-04-18 19:16 ` Hugh Dickins
2014-04-19 11:23 ` 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=535195F3.8040009@intel.com \
--to=dave.hansen@intel.com \
--cc=andi@firstfloor.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mgorman@suse.de \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).