From: Michal Hocko <mhocko@suse.cz>
To: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
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 11:50:49 +0200 [thread overview]
Message-ID: <20100903095049.GG10686@tiehlicka.suse.cz> (raw)
In-Reply-To: <20100903181327.7dad3f84.kamezawa.hiroyu@jp.fujitsu.com>
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?
>
> > > +
> > > + 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.
Thanks
--
Michal Hocko
L3 team
SUSE LINUX s.r.o.
Lihovarska 1060/12
190 00 Praha 9
Czech Republic
--
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>
next prev parent reply other threads:[~2010-09-03 9:50 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 [this message]
2010-09-03 10:05 ` KAMEZAWA Hiroyuki
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=20100903095049.GG10686@tiehlicka.suse.cz \
--to=mhocko@suse.cz \
--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.hiroyu@jp.fujitsu.com \
--cc=kamezawa.hiroyuki@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mel@linux.vnet.ibm.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