linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Minchan Kim <minchan.kim@gmail.com>
To: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
Cc: Mel Gorman <mgorman@suse.de>,
	Andrew Morton <akpm@linux-foundation.org>,
	linux-mm <linux-mm@kvack.org>,
	LKML <linux-kernel@vger.kernel.org>,
	Christoph Lameter <cl@linux.com>,
	Johannes Weiner <jweiner@redhat.com>,
	KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>,
	Rik van Riel <riel@redhat.com>,
	Andrea Arcangeli <aarcange@redhat.com>
Subject: Re: [RFC 6/8] In order putback lru core
Date: Mon, 2 May 2011 00:29:10 +0900	[thread overview]
Message-ID: <BANLkTikHf+3vhnXFu3ubWXOXkCkD4j206Q@mail.gmail.com> (raw)
In-Reply-To: <20110501224844.75EC.A69D9226@jp.fujitsu.com>

On Sun, May 1, 2011 at 10:47 PM, KOSAKI Motohiro
<kosaki.motohiro@jp.fujitsu.com> wrote:
>> > +/* This structure is used for keeping LRU ordering of isolated page */
>> > +struct pages_lru {
>> > +        struct page *page;      /* isolated page */
>> > +        struct page *prev_page; /* previous page of isolate page as LRU order */
>> > +        struct page *next_page; /* next page of isolate page as LRU order */
>> > +        struct list_head lru;
>> > +};
>> >  /*
>>
>> So this thing has to be allocated from somewhere. We can't put it
>> on the stack as we're already in danger there so we must be using
>> kmalloc. In the reclaim paths, this should be avoided obviously.
>> For compaction, we might hurt the compaction success rates if pages
>> are pinned with control structures. It's something to be wary of.
>>
>> At LSF/MM, I stated a preference for swapping the source and
>> destination pages in the LRU. This unfortunately means that the LRU
>> now contains a page in the process of being migrated to and the backout
>> paths for migration failure become a lot more complex. Reclaim should
>> be ok as it'll should fail to lock the page and recycle it in the list.
>> This avoids allocations but I freely admit that I'm not in the position
>> to implement such a thing right now :(
>
> I like swaping to fake page. one way pointer might become dangerous. vmscan can
> detect fake page and ignore it.


I guess it means swapping between migrated-from page and migrated-to page.
Right? If so, migrated-from page is already removed from LRU list and
migrated-to page isn't LRU as it's page allocated newly so they don't
have any LRU information. How can we swap them? We need space keeps
LRU information before removing the page from LRU list. :(

Could you explain in detail about swapping if I miss something?

About one way pointer, I think it's no problem. Worst case I imagine
is to put the page in head of LRU list. It means it's same issue now.
So it doesn't make worse than now.

>
> ie,
> is_fake_page(page)
> {
>        if (is_stack_addr((void*)page))
>                return true;
>        return false;
> }
>
> Also, I like to use stack rather than kmalloc in compaction.
>

Compaction is a procedure of reclaim. As you know, we had a problem
about using of stack during reclaim path.
I admit kmalloc-thing isn't good.
I will try to solve the issue as TODO.

Thanks for the review, KOSAKI.


-- 
Kind regards,
Minchan Kim

--
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/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

  reply	other threads:[~2011-05-01 15:29 UTC|newest]

Thread overview: 52+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-04-26 16:25 [RFC 0/8] Prevent LRU churing Minchan Kim
2011-04-26 16:25 ` [RFC 1/8] Only isolate page we can handle Minchan Kim
2011-04-27  7:54   ` KAMEZAWA Hiroyuki
2011-04-27  8:12     ` Minchan Kim
2011-04-27  8:13   ` Minchan Kim
2011-04-28 10:26   ` Mel Gorman
2011-04-26 16:25 ` [RFC 2/8] compaction: make isolate_lru_page with filter aware Minchan Kim
2011-04-27  7:55   ` KAMEZAWA Hiroyuki
2011-04-28  8:48   ` Johannes Weiner
2011-04-29 15:15     ` Minchan Kim
2011-05-01  7:27       ` KOSAKI Motohiro
2011-04-28 10:31   ` Mel Gorman
2011-04-26 16:25 ` [RFC 3/8] vmscan: " Minchan Kim
2011-04-27  8:03   ` KAMEZAWA Hiroyuki
2011-04-27 23:18     ` Minchan Kim
2011-04-28  8:54     ` Johannes Weiner
2011-04-28  9:10       ` KAMEZAWA Hiroyuki
2011-04-28 10:26         ` Johannes Weiner
2011-04-28 10:35   ` Mel Gorman
2011-04-29 15:18     ` Minchan Kim
2011-04-26 16:25 ` [RFC 4/8] Make clear description of putback_lru_page Minchan Kim
2011-04-27  8:11   ` KAMEZAWA Hiroyuki
2011-04-27 23:20     ` Minchan Kim
2011-04-28  8:45       ` Johannes Weiner
2011-05-01 13:13         ` KOSAKI Motohiro
2011-05-01 15:10           ` Minchan Kim
2011-04-26 16:25 ` [RFC 5/8] compaction: remove active list counting Minchan Kim
2011-04-27  8:15   ` KAMEZAWA Hiroyuki
2011-04-27 23:42     ` Minchan Kim
2011-04-28  9:02       ` Johannes Weiner
2011-04-28  8:58   ` Johannes Weiner
2011-04-29 15:19     ` Minchan Kim
2011-04-28 10:50   ` Mel Gorman
2011-04-29 15:25     ` Minchan Kim
2011-05-01 13:19       ` KOSAKI Motohiro
2011-05-01 15:09         ` Minchan Kim
2011-04-26 16:25 ` [RFC 6/8] In order putback lru core Minchan Kim
2011-04-27  4:20   ` Minchan Kim
2011-04-27  8:34   ` KAMEZAWA Hiroyuki
2011-04-27 23:43     ` Minchan Kim
2011-04-27 23:46   ` Rik van Riel
2011-04-27 23:59     ` Minchan Kim
2011-04-28 11:06   ` Mel Gorman
2011-04-29 15:47     ` Minchan Kim
2011-05-01 13:47     ` KOSAKI Motohiro
2011-05-01 15:29       ` Minchan Kim [this message]
2011-05-09  3:21         ` KOSAKI Motohiro
2011-04-26 16:25 ` [RFC 7/8] migration: make in-order-putback aware Minchan Kim
2011-04-26 16:25 ` [RFC 8/8] compaction: make compaction use in-order putback Minchan Kim
2011-04-27  4:22   ` Minchan Kim
2011-04-27  8:39   ` KAMEZAWA Hiroyuki
2011-04-27  9:08     ` Minchan Kim

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=BANLkTikHf+3vhnXFu3ubWXOXkCkD4j206Q@mail.gmail.com \
    --to=minchan.kim@gmail.com \
    --cc=aarcange@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=cl@linux.com \
    --cc=jweiner@redhat.com \
    --cc=kamezawa.hiroyu@jp.fujitsu.com \
    --cc=kosaki.motohiro@jp.fujitsu.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mgorman@suse.de \
    --cc=riel@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).