All of lore.kernel.org
 help / color / mirror / Atom feed
From: Rik van Riel <riel@redhat.com>
To: Leon Romanovsky <leon@leon.nu>,
	Ebru Akagunduz <ebru.akagunduz@gmail.com>
Cc: Linux-MM <linux-mm@kvack.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	kirill.shutemov@linux.intel.com, n-horiguchi@ah.jp.nec.com,
	aarcange <aarcange@redhat.com>,
	iamjoonsoo.kim@lge.com, Xiexiuqi <xiexiuqi@huawei.com>,
	gorcunov@openvz.org,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Mel Gorman <mgorman@suse.de>,
	rientjes@google.com, Vlastimil Babka <vbabka@suse.cz>,
	aneesh.kumar@linux.vnet.ibm.com, hughd@google.com,
	Johannes Weiner <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 01:43:03 -0400	[thread overview]
Message-ID: <557E65E7.9010000@redhat.com> (raw)
In-Reply-To: <CALq1K=JzAWt2NUB8SOitBcXeegFTA5OOUm7NsxE3RGTzkuWfuA@mail.gmail.com>

On 06/15/2015 01:40 AM, Leon Romanovsky wrote:
> On Sun, Jun 14, 2015 at 6:04 PM, Ebru Akagunduz
> <ebru.akagunduz@gmail.com> 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;
> Sorry for asking, my knoweldge of THP is very limited, but why did you
> choose this default value?
> From the discussion followed by your patch
> (https://lkml.org/lkml/2015/2/27/432), I got an impression that it is
> not necessary right value.

I believe that Ebru's main focus for this initial version of
the patch series was to get the _mechanism_ (patch 3) right,
while having a fairly simple policy to drive it.

Any suggestions on when it is a good idea to bring in pages
from swap, and whether to treat resident-in-swap-cache pages
differently from need-to-be-paged-in pages, and what other
factors should be examined, are very welcome...

-- 
All rights reversed

WARNING: multiple messages have this Message-ID (diff)
From: Rik van Riel <riel@redhat.com>
To: Leon Romanovsky <leon@leon.nu>,
	Ebru Akagunduz <ebru.akagunduz@gmail.com>
Cc: Linux-MM <linux-mm@kvack.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	kirill.shutemov@linux.intel.com, n-horiguchi@ah.jp.nec.com,
	aarcange <aarcange@redhat.com>,
	iamjoonsoo.kim@lge.com, Xiexiuqi <xiexiuqi@huawei.com>,
	gorcunov@openvz.org,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Mel Gorman <mgorman@suse.de>,
	rientjes@google.com, Vlastimil Babka <vbabka@suse.cz>,
	aneesh.kumar@linux.vnet.ibm.com, hughd@google.com,
	Johannes Weiner <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 01:43:03 -0400	[thread overview]
Message-ID: <557E65E7.9010000@redhat.com> (raw)
In-Reply-To: <CALq1K=JzAWt2NUB8SOitBcXeegFTA5OOUm7NsxE3RGTzkuWfuA@mail.gmail.com>

On 06/15/2015 01:40 AM, Leon Romanovsky wrote:
> On Sun, Jun 14, 2015 at 6:04 PM, Ebru Akagunduz
> <ebru.akagunduz@gmail.com> 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;
> Sorry for asking, my knoweldge of THP is very limited, but why did you
> choose this default value?
> From the discussion followed by your patch
> (https://lkml.org/lkml/2015/2/27/432), I got an impression that it is
> not necessary right value.

I believe that Ebru's main focus for this initial version of
the patch series was to get the _mechanism_ (patch 3) right,
while having a fairly simple policy to drive it.

Any suggestions on when it is a good idea to bring in pages
from swap, and whether to treat resident-in-swap-cache pages
differently from need-to-be-paged-in pages, and what other
factors should be examined, are very welcome...

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

  reply	other threads:[~2015-06-15  5:43 UTC|newest]

Thread overview: 30+ 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 ` Ebru Akagunduz
2015-06-14 15:04 ` [RFC 1/3] mm: add tracepoint for scanning pages Ebru Akagunduz
2015-06-14 15:04   ` Ebru Akagunduz
2015-06-15  1:04   ` Rik van Riel
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-14 15:04   ` Ebru Akagunduz
2015-06-15  5:40   ` Leon Romanovsky
2015-06-15  5:40     ` Leon Romanovsky
2015-06-15  5:43     ` Rik van Riel [this message]
2015-06-15  5:43       ` Rik van Riel
2015-06-15  6:08       ` Leon Romanovsky
2015-06-15  6:08         ` Leon Romanovsky
2015-06-15  6:35         ` Rik van Riel
2015-06-15  6:35           ` Rik van Riel
2015-06-15 14:05   ` Rik van Riel
2015-06-15 14:05     ` Rik van Riel
2015-06-15 16:07     ` Leon Romanovsky
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-14 15:04   ` Ebru Akagunduz
2015-06-15 13:59   ` Rik van Riel
2015-06-15 13:59     ` Rik van Riel
2015-06-16 21:15   ` Andrew Morton
2015-06-16 21:15     ` Andrew Morton
2015-06-17  3:20     ` Rik van Riel
2015-06-17  3:20       ` Rik van Riel
2015-06-17 17:38       ` Ebru Akagunduz
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=557E65E7.9010000@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=leon@leon.nu \
    --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 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.