From: Arjan van de Ven <arjan@linux.intel.com>
To: Hugh Dickins <hughd@google.com>
Cc: Andrea Arcangeli <aarcange@redhat.com>,
Davidlohr Bueso <dave@stgolabs.net>,
linux-mm@kvack.org, Petr Holasek <pholasek@redhat.com>,
Andrew Morton <akpm@linux-foundation.org>,
Mel Gorman <mgorman@techsingularity.net>
Subject: Re: [PATCH 1/1] ksm: introduce ksm_max_page_sharing per page deduplication limit
Date: Mon, 18 Jan 2016 06:43:41 -0800 [thread overview]
Message-ID: <569CFA1D.4030401@linux.intel.com> (raw)
In-Reply-To: <alpine.LSU.2.11.1601172345340.1538@eggly.anvils>
>>
>> And the long hang do happen... once you start getting a bit of memory
>> pressure
>> (say you go from 7000 to 7200 VMs and you only have memory for 7150) then you
>> are hitting the long delays *for every page* the VM inspects, and it will
>
> I don't understand "*for every page*": why for *every* page?
> I won't dispute "for many pages, many more than is bearable".
for every page the VM inspects; the VM tries to free memory and goes on trying
to free stuff, but (I'm guessing here) skipping active pages, but to know and clear
active, you need to walk the whole chain. for each page.
>> Now, you can make it 2x faster (reboot in 12 hours? ;-) ) but there's really
>> a much
>> higher order reduction of the "long chain" problem needed...
>> I'm with Andrea that prevention of super long chains is the way to go, we can
>> argue about 250
>> or 500 or 1000. Numbers will speak there... but from a KSM user perspective,
>> at some point
>> you reduced the cost of a page by 250x or 500x or 1000x... it's hitting
>> diminishing returns.
>
> I'm not for a moment denying that there's a problem to be solved,
> just questioning what's the right solution.
>
> The reclaim case you illustrate does not persuade me, I already suggested
> an easier way to handle that (don't waste time on pages of high mapcount).
>
> Or are you saying that in your usage, the majority of pages start out with
> high mapcount? That would defeat my suggestion, I think, But it's the
> compaction case I want to think more about, that may persuade me also.
well in most servers that host VMs, of the, say 128Gb to 240Gb, all but a few hundred MB
is allocated to VMs, and VM memory is generally shared. So yes a big chunk
of memory will have a high map count of some sorts.
>
--
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:[~2016-01-18 14:43 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-11-10 18:44 RFC [PATCH 0/1] ksm: introduce ksm_max_page_sharing per page deduplication limit Andrea Arcangeli
2015-11-10 18:44 ` [PATCH 1/1] " Andrea Arcangeli
2015-12-09 16:19 ` Petr Holasek
2015-12-09 17:15 ` Andrea Arcangeli
2015-12-09 18:10 ` Andrea Arcangeli
2015-12-10 16:06 ` Petr Holasek
2015-12-11 0:31 ` Andrew Morton
2016-01-14 23:36 ` Hugh Dickins
2016-01-16 17:49 ` Andrea Arcangeli
2016-01-16 18:00 ` Arjan van de Ven
2016-01-18 8:14 ` Hugh Dickins
2016-01-18 14:43 ` Arjan van de Ven [this message]
2016-01-18 9:10 ` Hugh Dickins
2016-01-18 9:45 ` Hugh Dickins
2016-01-18 17:46 ` Andrea Arcangeli
2016-03-17 21:34 ` Hugh Dickins
2016-03-17 21:50 ` Andrew Morton
2016-03-18 16:27 ` Andrea Arcangeli
2016-01-18 11:01 ` Mel Gorman
2016-01-18 22:19 ` Andrea Arcangeli
2016-01-19 10:43 ` Mel Gorman
2016-04-06 20:33 ` Rik van Riel
2016-04-06 22:02 ` Andrea Arcangeli
2016-09-21 15:12 ` Gavin Guo
2016-09-21 15:34 ` Andrea Arcangeli
2016-09-22 10:48 ` Gavin Guo
2016-10-28 6:26 ` Gavin Guo
2016-10-28 18:31 ` Andrea Arcangeli
2017-04-20 3:14 ` Gavin Guo
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=569CFA1D.4030401@linux.intel.com \
--to=arjan@linux.intel.com \
--cc=aarcange@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=dave@stgolabs.net \
--cc=hughd@google.com \
--cc=linux-mm@kvack.org \
--cc=mgorman@techsingularity.net \
--cc=pholasek@redhat.com \
/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).