All of lore.kernel.org
 help / color / mirror / Atom feed
From: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
To: minchan.kim@gmail.com
Cc: akpm@linux-foundation.org, linux-mm@kvack.org,
	linux-kernel@vger.kernel.org, jweiner@redhat.com, mel@csn.ul.ie,
	riel@redhat.com, lee.schermerhorn@hp.com
Subject: Re: [PATCH] vmscan: add barrier to prevent evictable page in unevictable list
Date: Wed, 28 Sep 2011 11:48:28 +0900	[thread overview]
Message-ID: <4E828AFC.7070405@jp.fujitsu.com> (raw)
In-Reply-To: <20110928022510.GB12100@barrios-desktop>

(2011/09/28 11:25), Minchan Kim wrote:
> On Wed, Sep 28, 2011 at 11:21:58AM +0900, KOSAKI Motohiro wrote:
>> (2011/09/28 10:45), Minchan Kim wrote:
>>> When racing between putback_lru_page and shmem_unlock happens,
>>> progrom execution order is as follows, but clear_bit in processor #1
>>> could be reordered right before spin_unlock of processor #1.
>>> Then, the page would be stranded on the unevictable list.
>>>
>>> spin_lock
>>> SetPageLRU
>>> spin_unlock
>>>                                 clear_bit(AS_UNEVICTABLE)
>>>                                 spin_lock
>>>                                 if PageLRU()
>>>                                         if !test_bit(AS_UNEVICTABLE)
>>>                                         	move evictable list
>>> smp_mb
>>> if !test_bit(AS_UNEVICTABLE)
>>>         move evictable list
>>>                                 spin_unlock
>>>
>>> But, pagevec_lookup in scan_mapping_unevictable_pages has rcu_read_[un]lock so
>>> it could protect reordering before reaching test_bit(AS_UNEVICTABLE) on processor #1
>>> so this problem never happens. But it's a unexpected side effect and we should
>>> solve this problem properly.
>>
>> Do we still need this after Hannes removes scan_mapping_unevictable_pages?
>  
> Hi KOSAKI,
> 
> What Hannes removes is scan_zone_unevictable_pages not scan_mapping_unevictable_pages.
> 

Oops, you are right.




WARNING: multiple messages have this Message-ID (diff)
From: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
To: minchan.kim@gmail.com
Cc: akpm@linux-foundation.org, linux-mm@kvack.org,
	linux-kernel@vger.kernel.org, jweiner@redhat.com, mel@csn.ul.ie,
	riel@redhat.com, lee.schermerhorn@hp.com
Subject: Re: [PATCH] vmscan: add barrier to prevent evictable page in unevictable list
Date: Wed, 28 Sep 2011 11:48:28 +0900	[thread overview]
Message-ID: <4E828AFC.7070405@jp.fujitsu.com> (raw)
In-Reply-To: <20110928022510.GB12100@barrios-desktop>

(2011/09/28 11:25), Minchan Kim wrote:
> On Wed, Sep 28, 2011 at 11:21:58AM +0900, KOSAKI Motohiro wrote:
>> (2011/09/28 10:45), Minchan Kim wrote:
>>> When racing between putback_lru_page and shmem_unlock happens,
>>> progrom execution order is as follows, but clear_bit in processor #1
>>> could be reordered right before spin_unlock of processor #1.
>>> Then, the page would be stranded on the unevictable list.
>>>
>>> spin_lock
>>> SetPageLRU
>>> spin_unlock
>>>                                 clear_bit(AS_UNEVICTABLE)
>>>                                 spin_lock
>>>                                 if PageLRU()
>>>                                         if !test_bit(AS_UNEVICTABLE)
>>>                                         	move evictable list
>>> smp_mb
>>> if !test_bit(AS_UNEVICTABLE)
>>>         move evictable list
>>>                                 spin_unlock
>>>
>>> But, pagevec_lookup in scan_mapping_unevictable_pages has rcu_read_[un]lock so
>>> it could protect reordering before reaching test_bit(AS_UNEVICTABLE) on processor #1
>>> so this problem never happens. But it's a unexpected side effect and we should
>>> solve this problem properly.
>>
>> Do we still need this after Hannes removes scan_mapping_unevictable_pages?
>  
> Hi KOSAKI,
> 
> What Hannes removes is scan_zone_unevictable_pages not scan_mapping_unevictable_pages.
> 

Oops, you are right.



--
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-09-28  2:45 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-09-28  1:45 [PATCH] vmscan: add barrier to prevent evictable page in unevictable list Minchan Kim
2011-09-28  1:45 ` Minchan Kim
2011-09-28  2:21 ` KOSAKI Motohiro
2011-09-28  2:21   ` KOSAKI Motohiro
2011-09-28  2:25   ` Minchan Kim
2011-09-28  2:25     ` Minchan Kim
2011-09-28  2:48     ` KOSAKI Motohiro [this message]
2011-09-28  2:48       ` KOSAKI Motohiro
2011-09-28  8:14 ` Johannes Weiner
2011-09-28  8:14   ` Johannes Weiner
2011-09-28 18:03   ` Minchan Kim
2011-09-28 18:03     ` Minchan Kim
2011-09-29  9:54   ` [PATCH v2] " Minchan Kim
2011-09-29  9:54     ` Minchan Kim
2011-09-29 12:50     ` KOSAKI Motohiro
2011-09-29 12:50       ` KOSAKI Motohiro
2011-09-28 15:04 ` [PATCH] " Lin Ming
2011-09-28 15:04   ` Lin Ming
2011-09-28 18:05   ` Minchan Kim
2011-09-28 18:05     ` Minchan Kim
2011-09-29  1:02     ` Lin Ming
2011-09-29  1:02       ` Lin Ming

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=4E828AFC.7070405@jp.fujitsu.com \
    --to=kosaki.motohiro@jp.fujitsu.com \
    --cc=akpm@linux-foundation.org \
    --cc=jweiner@redhat.com \
    --cc=lee.schermerhorn@hp.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mel@csn.ul.ie \
    --cc=minchan.kim@gmail.com \
    --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 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.