From: Badari Pulavarty <pbadari@us.ibm.com>
To: Dave Hansen <haveblue@us.ibm.com>
Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>,
melgor@ie.ibm.com, linux-mm <linux-mm@kvack.org>
Subject: Re: [PATCH 2/2] Add mem_type in /syfs to show memblock migrate type
Date: Thu, 25 Oct 2007 10:07:22 -0700 [thread overview]
Message-ID: <1193332042.9894.10.camel@dyn9047017100.beaverton.ibm.com> (raw)
In-Reply-To: <1193331162.4039.141.camel@localhost>
On Thu, 2007-10-25 at 09:52 -0700, Dave Hansen wrote:
> On Thu, 2007-10-25 at 08:55 -0700, Badari Pulavarty wrote:
> >
> > +static ssize_t show_mem_type(struct sys_device *dev, char *buf)
> > +{
> > + struct page *page;
> > + int type;
> > + int i = pageblock_nr_pages;
> > + struct memory_block *mem =
> > + container_of(dev, struct memory_block, sysdev);
> > +
> > + /*
> > + * Get the type of first page in the block
> > + */
> > + page = pfn_to_page(section_nr_to_pfn(mem->phys_index));
> > + type = get_pageblock_migratetype(page);
> > +
> > + /*
> > + * Check the migrate type of other pages in this section.
> > + * If the type doesn't match, report it.
> > + */
> > + while (i < PAGES_PER_SECTION) {
> > + if (type != get_pageblock_migratetype(page + i))
> > + return sprintf(buf, "Multiple\n");
> > + i += pageblock_nr_pages;
> > + }
>
> I might change this to be a bit more generic. The odds are that the
> existence of a "pageblock" or the types of "pageblocks" will either
> change or go away over time.
>
> But, a simple boolean "yes you have a good shot of removing this memory"
> or "you have a snowball's chance in hell" on removability is likely
> generic enough to stand the test of time.
>
> That is, after all, what you're after here, right?
>
> So, I'd rewrite that loop to look for the removable pageblock types and
> see if the entire section is make up of removable pageblocks, or if it
> has some party crashing non-removable pageblocks in ther.
I agree with you that all I care about are the "movable" sections
for remove. But what we are doing here is, exporting the migrate type
to user-space and let the user space make a decision on what type
of sections to use for its use. For now, we can migrate/remove ONLY
"movable" sections. But in the future, we may be able to migrate/remove
"Reclaimable" ones. I don't know.
I don't want to make decisions in the kernel for removability - as
it might change depending on the situation. All I want is to export
the info and let user-space deal with the decision making.
Thanks,
Badari
--
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:[~2007-10-25 17:03 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-10-25 15:55 Badari Pulavarty
2007-10-25 16:07 ` Mel Gorman
2007-10-25 16:52 ` Dave Hansen
2007-10-25 17:07 ` Badari Pulavarty [this message]
2007-10-25 17:15 ` Dave Hansen
2007-10-25 17:36 ` Badari Pulavarty
2007-10-25 17:34 ` Dave Hansen
2007-10-25 18:05 ` Mel Gorman
2007-10-25 18:12 ` Dave Hansen
2007-10-26 9:50 ` Mel Gorman
2007-10-26 15:52 ` Dave Hansen
2007-10-26 16:14 ` Mel Gorman
2007-10-26 17:18 ` Dave Hansen
-- strict thread matches above, loose matches on Subject: below --
2007-10-24 16:37 Badari Pulavarty
2007-10-25 10:17 ` Mel Gorman
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=1193332042.9894.10.camel@dyn9047017100.beaverton.ibm.com \
--to=pbadari@us.ibm.com \
--cc=haveblue@us.ibm.com \
--cc=kamezawa.hiroyu@jp.fujitsu.com \
--cc=linux-mm@kvack.org \
--cc=melgor@ie.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