;
> Signed-off-by: Mel Gorman
> Tested-by: Tony Prisk
Acked-by: Minchan Kim
--
Kind Regards,
Minchan Kim
= pageblock_nr_pages)
> > > > > {
> > > > > + struct page *page;
> > > > > + if (!pfn_valid(pfn))
> > > > > + continue;
> > > > > +
> > > > > + page = pfn_to_page(pfn);
> > > > > + if (zone != page_zone(page))
> > > > > + continue;
> > > > > +
> > > > > + clear_pageblock_skip(page);
> > > > > + }
> > > >
> > > > What's the worst-case loop count here?
> > > >
> > >
> > > zone->spanned_pages >> pageblock_order
> >
> > What's the worst-case value of (zone->spanned_pages >> pageblock_order) :)
>
> Lets take an unlikely case - 128G single-node machine. That loop count
> on x86-64 would be 65536. It'll be fast enough, particularly in this
> path.
>
> --
> Mel Gorman
> SUSE Labs
>
> --
> To unsubscribe, send a message with 'unsubscribe linux-mm' in
> the body to majord...@kvack.org. For more info on Linux MM,
> see: http://www.linux-mm.org/ .
> Don't email: mailto:"d...@kvack.org";> em...@kvack.org
--
Kind regards,
Minchan Kim
On Tue, Sep 25, 2012 at 02:39:31PM -0700, Andrew Morton wrote:
> On Tue, 25 Sep 2012 17:13:27 +0900
> Minchan Kim wrote:
>
> > I see. To me, your saying is better than current comment.
> > I hope comment could be more explicit.
> >
> > diff --git a/mm/compact
ock for as long as possible. In the
> event there are no free pages in the pageblock then the lock will not be
> acquired at all which reduces contention on zone->lock.
>
> Signed-off-by: Mel Gorman
> Acked-by: Rik van Riel
Acked-by: Minchan Kim
--
Kind regards,
Minchan Kim
On Tue, Sep 25, 2012 at 08:51:05AM +0100, Mel Gorman wrote:
> On Tue, Sep 25, 2012 at 04:05:17PM +0900, Minchan Kim wrote:
> > Hi Mel,
> >
> > I have a question below.
> >
> > On Fri, Sep 21, 2012 at 11:46:19AM +0100, Mel Gorman wrote:
> > > Com
Arcangeli
> Signed-off-by: Shaohua Li
> Signed-off-by: Mel Gorman
> Acked-by: Rik van Riel
Acked-by: Minchan Kim
--
Kind regards,
Minchan Kim
nners.
>
> Signed-off-by: Mel Gorman
> Acked-by: Rik van Riel
Acked-by: Minchan Kim
--
Kind regards,
Minchan Kim
pfn_valid_within()?
> >
>
> Comment is stale and should be removed.
>
> > > @@ -218,13 +272,18 @@ static unsigned long
> > > isolate_freepages_block(unsigned long blockpfn,
> > > unsigned long
> > > isolate_freepages_range(unsigned long start_pfn, unsigned long end_pfn)
> > > {
> > > - unsigned long isolated, pfn, block_end_pfn, flags;
> > > + unsigned long isolated, pfn, block_end_pfn;
> > > struct zone *zone = NULL;
> > > LIST_HEAD(freelist);
> > > + struct compact_control cc;
> > >
> > > if (pfn_valid(start_pfn))
> > > zone = page_zone(pfn_to_page(start_pfn));
> > >
> > > + /* cc needed for isolate_freepages_block to acquire zone->lock */
> > > + cc.zone = zone;
> > > + cc.sync = true;
> >
> > We initialise two of cc's fields, leave the other 12 fields containing
> > random garbage, then start using it. I see no bug here, but...
> >
>
> I get your point. At the very least we should initialise it with zeros.
>
> How about this?
>
> ---8<---
> mm: compaction: Iron out isolate_freepages_block() and
> isolate_freepages_range()
>
> Andrew pointed out that isolate_freepages_block() is "straggly" and
> isolate_freepages_range() is making assumptions on how compact_control is
> used which is delicate. This patch straightens isolate_freepages_block()
> and makes it fly straight and initialses compact_control to zeros in
> isolate_freepages_range(). The code should be easier to follow and
> is functionally equivalent. The CMA failure path is now a little more
> expensive but that is a marginal corner-case.
>
> Signed-off-by: Mel Gorman
Acked-by: Minchan Kim
--
Kind regards,
Minchan Kim
> }
> @@ -444,6 +460,13 @@ isolate_migratepages_range(struct zone *zone, struct
> compact_control *cc,
> ++low_pfn;
> break;
> }
> +
> + continue;
> +
> +next_pageblock:
> + low_pfn += pageblock_nr_pages;
> + low_pfn = ALIGN(low_pfn, pageblock_nr_pages) - 1;
> + last_pageblock_nr = pageblock_nr;
> }
>
> acct_isolated(zone, locked, cc);
> --
> 1.7.9.2
>
> --
> To unsubscribe, send a message with 'unsubscribe linux-mm' in
> the body to majord...@kvack.org. For more info on Linux MM,
> see: http://www.linux-mm.org/ .
> Don't email: mailto:"d...@kvack.org";> em...@kvack.org
--
Kind regards,
Minchan Kim
cks from people who use/know
> hugetlbfs. Who would that be? I'm adding random people who have
> acked/signed-off patches to hugetlbfs recently..
At least, code itself looks good to me but your random choice was failed.
Maybe people you want are as follows.
http://marc.info/?t=12692897583&r=1&w=2
Ccing right persons.
--
Kind regards,
Minchan Kim
10 matches
Mail list logo
