linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
To: Michal Hocko <mhocko@suse.cz>
Cc: Hiroyuki Kamezawa <kamezawa.hiroyuki@gmail.com>,
	Wu Fengguang <fengguang.wu@intel.com>,
	"linux-mm@kvack.org" <linux-mm@kvack.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	"Kleen, Andi" <andi.kleen@intel.com>,
	Haicheng Li <haicheng.li@linux.intel.com>,
	Christoph Lameter <cl@linux-foundation.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Mel Gorman <mel@linux.vnet.ibm.com>
Subject: Re: [PATCH 2/2] Make is_mem_section_removable more conformable with offlining code
Date: Fri, 3 Sep 2010 19:05:20 +0900	[thread overview]
Message-ID: <20100903190520.8751aab6.kamezawa.hiroyu@jp.fujitsu.com> (raw)
In-Reply-To: <20100903095049.GG10686@tiehlicka.suse.cz>

On Fri, 3 Sep 2010 11:50:49 +0200
Michal Hocko <mhocko@suse.cz> wrote:

> On Fri 03-09-10 18:13:27, KAMEZAWA Hiroyuki wrote:
> > On Fri, 3 Sep 2010 10:25:58 +0200
> > Michal Hocko <mhocko@suse.cz> wrote:
> > 
> > > On Fri 03-09-10 12:14:52, KAMEZAWA Hiroyuki wrote:
> > > [...]
> [...]
> > > Cannot ZONE_MOVABLE contain different MIGRATE_types?
> > > 
> > never.
> 
> Then I am terribly missing something. Zone contains free lists for
> different MIGRATE_TYPES, doesn't it? Pages allocated from those free
> lists keep the migration type of the list, right?
> 
> ZONE_MOVABLE just says whether it makes sense to move pages in that zone
> at all, right?
> 

 ZONE_MOVABLE means "it only contains MOVABLE pages."
 So, we can ignore migrate-type.





> > 
> > > > +
> > > > +	pfn = page_to_pfn(page);
> > > > +	for (found = 0, iter = 0; iter < pageblock_nr_pages; iter++) {
> > > > +		unsigned long check = pfn + iter;
> > > > +
> > > > +		if (!pfn_valid_within(check)) {
> > > > +			iter++;
> > > > +			continue;
> > > > +		}
> > > > +		page = pfn_to_page(check);
> > > > +		if (!page_count(page)) {
> > > > +			if (PageBuddy(page))
> > > 
> > > Why do you check page_count as well? PageBuddy has alwyas count==0,
> > > right?
> > > 
> > 
> > But PageBuddy() flag is considered to be valid only when page_count()==0.
> > This is for safe handling.
> 
> OK. I don't see that documented anywhere but it makes sense. Anyway
> there are some places which don't do this test (e.g.
> isolate_freepages_block, suitable_migration_target, etc.).
> 
> > 
> > 
> > > > +				iter += (1 << page_order(page)) - 1;
> > > > +			continue;
> > > > +		}
> > > > +		if (!PageLRU(page))
> > > > +			found++;
> > > > +		/*
> > > > +		 * If the page is not RAM, page_count()should be 0.
> > > > +		 * we don't need more check. This is an _used_ not-movable page.
> > > > +		 *
> > > > +		 * The problematic thing here is PG_reserved pages. But if
> > > > +		 * a PG_reserved page is _used_ (at boot), page_count > 1.
> > > > +		 * But...is there PG_reserved && page_count(page)==0 page ?
> > > 
> > > Can we have PG_reserved && PG_lru? 
> > 
> > I think never.
> > 
> > > I also quite don't understand the comment. 
> > 
> > There an issue that "remove an memory section which includes memory hole".
> > Then,
> > 
> >    a page used by bootmem .... PG_reserved.
> >    a page of memory hole  .... PG_reserved.
> > 
> > We need to call page_is_ram() or some for handling this mess.
> 
> OK, I see.
> 
> > 
> > 
> > > At this place we are sure that the page is valid and neither
> > > free nor LRU.
> > > 
> [...]
> > > > +bool is_pageblock_removable(struct page *page)
> > > > +{
> > > > +	struct zone *zone = page_zone(page);
> > > > +	unsigned long flags;
> > > > +	int num;
> > > > +
> > > > +	spin_lock_irqsave(&zone->lock, flags);
> > > > +	num = __count_unmovable_pages(zone, page);
> > > > +	spin_unlock_irqrestore(&zone->lock, flags);
> > > 
> > > Isn't this a problem? The function is triggered from userspace by sysfs
> > > (0444 file) and holds the lock for pageblock_nr_pages. So someone can
> > > simply read the file and block the zone->lock preventing/delaying
> > > allocations for the rest of the system.
> > > 
> > But we need to take this. Maybe no panic you'll see even if no-lock.
> 
> Yes, I think that this can only lead to a false possitive in sysfs
> interface. Isolating code holds the lock.
> 

ok, let's go step by step.

I'm ok that your new patch to be merged. I'll post some clean up and small
bugfix (not related to your patch), later.
(I'll be very busy in this weekend, sorry.)


Thanks,
-Kame

--
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:[~2010-09-03 10:10 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-08-20 14:14 [PATCH] " Michal Hocko
2010-08-22  0:42 ` Wu Fengguang
2010-08-23  9:22   ` Michal Hocko
2010-08-31 12:30     ` Michal Hocko
2010-08-31 14:19     ` Wu Fengguang
2010-08-31 14:36       ` Wu Fengguang
2010-08-31 14:59         ` Wu Fengguang
2010-09-01  1:19         ` KAMEZAWA Hiroyuki
2010-09-01 12:19       ` Michal Hocko
2010-09-01 12:41         ` Michal Hocko
2010-09-02  5:45           ` KAMEZAWA Hiroyuki
2010-09-02  8:28             ` Michal Hocko
2010-09-02  9:03               ` KAMEZAWA Hiroyuki
2010-09-02  9:24                 ` Michal Hocko
2010-09-02 11:19                   ` Hiroyuki Kamezawa
2010-09-02 13:18                     ` Michal Hocko
2010-09-02 14:19                       ` Hiroyuki Kamezawa
2010-09-02 14:39                         ` Michal Hocko
2010-09-02 15:05                           ` Michal Hocko
2010-09-03  3:10                             ` [PATCH 0/2 v2] " KAMEZAWA Hiroyuki
2010-09-03  3:11                               ` [PATCH 1/2][BUGFIX] fix next active pageblock calculation KAMEZAWA Hiroyuki
2010-09-03  3:14                               ` [PATCH 2/2] Make is_mem_section_removable more conformable with offlining code KAMEZAWA Hiroyuki
2010-09-03  8:25                                 ` Michal Hocko
2010-09-03  9:13                                   ` KAMEZAWA Hiroyuki
2010-09-03  9:50                                     ` Michal Hocko
2010-09-03 10:05                                       ` KAMEZAWA Hiroyuki [this message]
2010-09-03 11:01                                         ` Michal Hocko
2010-09-03 11:42                                         ` [PATCH 2/2] Make is_mem_section_removable more conformable with offlining code v3 Michal Hocko
2010-09-04  2:55                                           ` Wu Fengguang
2010-09-06  9:16                                             ` Michal Hocko
2010-09-03  9:15                                   ` [PATCH 2/2] Make is_mem_section_removable more conformable with offlining code Michal Hocko
2010-09-03  9:24                                     ` KAMEZAWA Hiroyuki
2010-09-03  7:54                               ` [PATCH 0/2 v2] " Michal Hocko
2010-09-03  7:57                               ` [PATCH 3/2][BUGFIX] fix memory isolation notifier return value check KAMEZAWA Hiroyuki
2010-09-03 20:48                                 ` Andrew Morton
2010-09-03 22:05                                   ` Hiroyuki Kamezawa

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=20100903190520.8751aab6.kamezawa.hiroyu@jp.fujitsu.com \
    --to=kamezawa.hiroyu@jp.fujitsu.com \
    --cc=akpm@linux-foundation.org \
    --cc=andi.kleen@intel.com \
    --cc=cl@linux-foundation.org \
    --cc=fengguang.wu@intel.com \
    --cc=haicheng.li@linux.intel.com \
    --cc=kamezawa.hiroyuki@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mel@linux.vnet.ibm.com \
    --cc=mhocko@suse.cz \
    /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