linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Rik van Riel <riel@redhat.com>
To: Ebru Akagunduz <ebru.akagunduz@gmail.com>, linux-mm@kvack.org
Cc: akpm@linux-foundation.org, kirill.shutemov@linux.intel.com,
	n-horiguchi@ah.jp.nec.com, aarcange@redhat.com,
	iamjoonsoo.kim@lge.com, xiexiuqi@huawei.com, gorcunov@openvz.org,
	linux-kernel@vger.kernel.org, mgorman@suse.de,
	rientjes@google.com, vbabka@suse.cz,
	aneesh.kumar@linux.vnet.ibm.com, hughd@google.com,
	hannes@cmpxchg.org, mhocko@suse.cz, boaz@plexistor.com,
	raindel@mellanox.com
Subject: Re: [RFC 2/3] mm: make optimistic check for swapin readahead
Date: Mon, 15 Jun 2015 10:05:22 -0400	[thread overview]
Message-ID: <557EDBA2.9090308@redhat.com> (raw)
In-Reply-To: <1434294283-8699-3-git-send-email-ebru.akagunduz@gmail.com>

On 06/14/2015 11:04 AM, Ebru Akagunduz wrote:
> This patch makes optimistic check for swapin readahead
> to increase thp collapse rate. Before getting swapped
> out pages to memory, checks them and allows up to a
> certain number. It also prints out using tracepoints
> amount of unmapped ptes.
> 
> Signed-off-by: Ebru Akagunduz <ebru.akagunduz@gmail.com>

> @@ -2639,11 +2640,11 @@ static int khugepaged_scan_pmd(struct mm_struct *mm,
>  {
>  	pmd_t *pmd;
>  	pte_t *pte, *_pte;
> -	int ret = 0, none_or_zero = 0;
> +	int ret = 0, none_or_zero = 0, unmapped = 0;
>  	struct page *page;
>  	unsigned long _address;
>  	spinlock_t *ptl;
> -	int node = NUMA_NO_NODE;
> +	int node = NUMA_NO_NODE, max_ptes_swap = HPAGE_PMD_NR/8;
>  	bool writable = false, referenced = false;

This has the effect of only swapping in 4kB pages to form a THP
if 7/8th of the THP is already resident in memory.

This is a pretty conservative thing to do.

I am not sure if we would also need to take into account things
like these:
1) How many pages in the THP-area are recently referenced?
   Maybe this does not matter if 87.5% of the 4kB pages got
   faulted in after swap-out, anyway?
2) How much free memory does the system have?
   We don't test that for collapsing a THP with lots of
   pte_none() ptes, so not sure how much this matters...
3) How many of the pages we want to swap in are already resident
   in the swap cache?
   Not sure exactly what to do with this number...
4) other factors?

I am also not sure how we would determine such a policy, except
by maybe having these patches sit in -mm and -next for a few
cycles, and seeing what happens...


-- 
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>

  parent reply	other threads:[~2015-06-15 14:05 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-06-14 15:04 [RFC 0/3] mm: make swapin readahead to gain more thp performance Ebru Akagunduz
2015-06-14 15:04 ` [RFC 1/3] mm: add tracepoint for scanning pages Ebru Akagunduz
2015-06-15  1:04   ` Rik van Riel
2015-06-14 15:04 ` [RFC 2/3] mm: make optimistic check for swapin readahead Ebru Akagunduz
2015-06-15  5:40   ` Leon Romanovsky
2015-06-15  5:43     ` Rik van Riel
2015-06-15  6:08       ` Leon Romanovsky
2015-06-15  6:35         ` Rik van Riel
2015-06-15 14:05   ` Rik van Riel [this message]
2015-06-15 16:07     ` Leon Romanovsky
2015-06-14 15:04 ` [RFC 3/3] mm: make swapin readahead to improve thp collapse rate Ebru Akagunduz
2015-06-15 13:59   ` Rik van Riel
2015-06-16 21:15   ` Andrew Morton
2015-06-17  3:20     ` Rik van Riel
2015-06-17 17:38       ` Ebru Akagunduz

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=557EDBA2.9090308@redhat.com \
    --to=riel@redhat.com \
    --cc=aarcange@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=aneesh.kumar@linux.vnet.ibm.com \
    --cc=boaz@plexistor.com \
    --cc=ebru.akagunduz@gmail.com \
    --cc=gorcunov@openvz.org \
    --cc=hannes@cmpxchg.org \
    --cc=hughd@google.com \
    --cc=iamjoonsoo.kim@lge.com \
    --cc=kirill.shutemov@linux.intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mgorman@suse.de \
    --cc=mhocko@suse.cz \
    --cc=n-horiguchi@ah.jp.nec.com \
    --cc=raindel@mellanox.com \
    --cc=rientjes@google.com \
    --cc=vbabka@suse.cz \
    --cc=xiexiuqi@huawei.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).