On Thu, Sep 06, 2012 at 02:25:51PM +0100, Mel Gorman wrote:
> On Thu, Sep 06, 2012 at 08:55:26PM +0800, Shaohua Li wrote:
> > On Thu, Sep 06, 2012 at 01:17:25PM +0100, Mel Gorman wrote:
> > > On Thu, Sep 06, 2012 at 06:44:04PM +0800, Shaohua Li wrote:
> > > >
> > > > isolate_migratepages_range() might isolate none pages, for example, when
> > > > zone->lru_lock is contended and compaction is async. In this case, we should
> > > > abort compaction, otherwise, compact_zone will run a useless loop and make
> > > > zone->lru_lock is even contended.
> > > >
> > >
> > > It might also isolate no pages because the range was 100% allocated and
> > > there were no free pages to isolate. This is perfectly normal and I suspect
> > > this patch effectively disables compaction. What problem did you observe
> > > that this patch is aimed at?
> >
> > I'm running a random swapin/out workload. When memory is fragmented enough, I
> > saw 100% cpu usage. perf shows zone->lru_lock is heavily contended in
> > isolate_migratepages_range. I'm using slub(I didn't see the problem with slab),
> > the allocation is for radix_tree_node slab, which needs 4 pages.
>
> Ok, the fragmentaiton is due to high-order unmovable kernel allocations from
> SLUB which will have diminishing returns over time. One option to address
> this is to check if it's a high-order kernel allocation that can fail and
> not compact in that case. SLUB will fall back to using order-0 instead.
I tried actually, and it doesn't help. The problem is compact_zone keeps
running isolate_migratepages_range, which does nothing except doing a
lock/unlock.
> > Even If I just
> > apply the second patch, the system is still in 100% cpu usage. The
> > spin_is_contended check can't cure the problem completely.
>
> Are you sure it's really contention in that case and not just a lot of
> time is spent in compaction trying to satisfy the radix_tree_node
> allocation requests?
certainly it's the contention.
> > Trace shows
> > compact_zone will run a useless loop and each loop contend the lru_lock. With
> > this patch, the cpu usage becomes normal (about 20% utilization).
>
> I suspect the reason why this patch has an effect is because compaction is
> no longer running. It finds a 100% full pageblock quickly and then aborts and
> that is not the right fix. Can you try something like this instead please?
That debug patch doesn't help. My system just hang.
I thought your worry is valid, we shouldn't abort if 100% full pageblock is
found. How about this one? With it, the cpu usage is normal in my workload.
Occassionally I saw cpu usage reaches high (up to 80%), but recovered
immediately. Without the patch, the cpu usage keeps in 100%.
Thanks,
Shaohua
Subject: compaction: check migrated page number
isolate_migratepages_range() might isolate none pages, for example, when
zone->lru_lock is contended and compaction is async. In this case, we should
abort compaction, otherwise, compact_zone will run a useless loop and make
zone->lru_lock is even contended.
Signed-off-by: Shaohua Li <shli@xxxxxxxxxxxx>
---
mm/compaction.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
Index: linux/mm/compaction.c
===================================================================
--- linux.orig/mm/compaction.c 2012-09-06 18:37:52.636413761 +0800
+++ linux/mm/compaction.c 2012-09-07 10:51:16.734081959 +0800
@@ -618,7 +618,7 @@ typedef enum {
static isolate_migrate_t isolate_migratepages(struct zone *zone,
struct compact_control *cc)
{
- unsigned long low_pfn, end_pfn;
+ unsigned long low_pfn, end_pfn, old_low_pfn;
/* Do not scan outside zone boundaries */
low_pfn = max(cc->migrate_pfn, zone->zone_start_pfn);
@@ -633,8 +633,9 @@ static isolate_migrate_t isolate_migrate
}
/* Perform the isolation */
+ old_low_pfn = low_pfn;
low_pfn = isolate_migratepages_range(zone, cc, low_pfn, end_pfn);
- if (!low_pfn)
+ if (!low_pfn || old_low_pfn == low_pfn)
return ISOLATE_ABORT;
cc->migrate_pfn = low_pfn;
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@xxxxxxxxx. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>