Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1500068

Re: Regression in mobility grouping?

Show all headers | View raw

Sorry for late response.

On Thu, Sep 29, 2016 at 12:14:02PM -0400, Johannes Weiner wrote:
> On Thu, Sep 29, 2016 at 03:14:33PM +0900, Joonsoo Kim wrote:
> > On Wed, Sep 28, 2016 at 10:25:40PM -0400, Johannes Weiner wrote:
> > > On Wed, Sep 28, 2016 at 11:39:25AM -0400, Johannes Weiner wrote:
> > > > On Wed, Sep 28, 2016 at 11:00:15AM +0200, Vlastimil Babka wrote:
> > > > > I guess testing revert of 9c0415e could give us some idea. Commit
> > > > > 3a1086f shouldn't result in pageblock marking differences and as I said
> > > > > above, 99592d5 should be just restoring to what 3.10 did.
> > > > 
> > > > I can give this a shot, but note that this commit makes only unmovable
> > > > stealing more aggressive. We see reclaimable blocks up as well.
> > > 
> > > Quick update, I reverted back to stealing eagerly only on behalf of
> > > MIGRATE_RECLAIMABLE allocations in a 4.6 kernel:
> > 
> > Hello, Johannes.
> > 
> > I think that it would be better to check 3.10 with above patches.
> > Fragmentation depends on not only policy itself but also
> > allocation/free pattern. There might be a large probability that
> > allocation/free pattern is changed in this large kernel version
> > difference.
> 
> You mean backport suspicious patches to 3.10 until I can reproduce it
> there? I'm not sure. You're correct, the patterns very likely *have*
> changed. But that alone cannot explain mobility grouping breaking that
> badly. There is a reproducable bad behavior. It should be easier to
> track down than to try to recreate it in the last-known-good kernel.

Okay. It is just my two cents.

> 
> > > This is an UNMOVABLE order-3 allocation falling back to RECLAIMABLE.
> > > According to can_steal_fallback(), this allocation shouldn't steal the
> > > pageblock, yet change_ownership=1 indicates the block is UNMOVABLE.
> > > 
> > > Who converted it? I wonder if there is a bug in ownership management,
> > > and there was an UNMOVABLE block on the RECLAIMABLE freelist from the
> > > beginning. AFAICS we never validate list/mt consistency anywhere.
> > 
> > According to my code review, it would be possible. When stealing
> > happens, we moved those buddy pages to current requested migratetype
> > buddy list. If the other migratetype allocation request comes and
> > stealing from the buddy list of previous requested migratetype
> > happens, change_ownership will show '1' even if there is no ownership
> > changing.
> 
> These two paths should exclude each other through the zone->lock, no?

zone->lock ensures that changing migratetype of pageblock happens
sequentially. But, it doesn't protect where actual freepage of some
pageblock is attached. For example, freepage on unmovable pageblock
could be attached on the movable buddy list and wrong information
about change_ownership=1 would be possible.

Thanks.

Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

Regression in mobility grouping? Johannes Weiner <hannes@cmpxchg.org> - 2016-09-28 03:50 +0200
  Re: Regression in mobility grouping? Vlastimil Babka <vbabka@suse.cz> - 2016-09-28 11:10 +0200
    Re: Regression in mobility grouping? Johannes Weiner <hannes@cmpxchg.org> - 2016-09-28 17:50 +0200
      Re: Regression in mobility grouping? Johannes Weiner <hannes@cmpxchg.org> - 2016-09-29 04:30 +0200
        Re: Regression in mobility grouping? Joonsoo Kim <iamjoonsoo.kim@lge.com> - 2016-09-29 08:10 +0200
          Re: Regression in mobility grouping? Johannes Weiner <hannes@cmpxchg.org> - 2016-09-29 18:20 +0200
            Re: Regression in mobility grouping? Joonsoo Kim <iamjoonsoo.kim@lge.com> - 2016-10-13 09:40 +0200
        Re: Regression in mobility grouping? Vlastimil Babka <vbabka@suse.cz> - 2016-09-29 09:20 +0200
  Re: Regression in mobility grouping? Mel Gorman <mgorman@suse.de> - 2016-09-28 12:30 +0200
    Re: Regression in mobility grouping? Johannes Weiner <hannes@cmpxchg.org> - 2016-09-28 18:50 +0200
  [RFC 2/4] mm, compaction: add migratetype to compact_control Vlastimil Babka <vbabka@suse.cz> - 2016-09-29 23:10 +0200
  [RFC 1/4] mm, compaction: change migrate_async_suitable() to suitable_migration_source() Vlastimil Babka <vbabka@suse.cz> - 2016-09-29 23:10 +0200
  [RFC 3/4] mm, compaction: restrict async compaction to matching migratetype Vlastimil Babka <vbabka@suse.cz> - 2016-09-29 23:10 +0200
  [RFC 4/4] mm, page_alloc: disallow migratetype fallback in fastpath Vlastimil Babka <vbabka@suse.cz> - 2016-09-29 23:10 +0200
    Re: [RFC 4/4] mm, page_alloc: disallow migratetype fallback in  fastpath Vlastimil Babka <vbabka@suse.cz> - 2016-10-12 17:20 +0200
    Re: [RFC 4/4] mm, page_alloc: disallow migratetype fallback in  fastpath Joonsoo Kim <iamjoonsoo.kim@lge.com> - 2016-10-13 10:00 +0200
      Re: [RFC 4/4] mm, page_alloc: disallow migratetype fallback in  fastpath Vlastimil Babka <vbabka@suse.cz> - 2016-10-13 13:50 +0200
  [RFC 0/4] try to reduce fragmenting fallbacks Vlastimil Babka <vbabka@suse.cz> - 2016-09-29 23:10 +0200
    [RFC 5/4] mm, page_alloc: split smallest stolen page in fallback Vlastimil Babka <vbabka@suse.cz> - 2016-10-07 10:40 +0200
    Re: [RFC 0/4] try to reduce fragmenting fallbacks Johannes Weiner <hannes@cmpxchg.org> - 2016-10-10 19:30 +0200
    [RFC 6/4] mm, page_alloc: introduce MIGRATE_MIXED migratetype Vlastimil Babka <vbabka@suse.cz> - 2016-10-11 15:20 +0200
    [RFC 7/4] mm, page_alloc: count movable pages when stealing Vlastimil Babka <vbabka@suse.cz> - 2016-10-13 16:20 +0200

csiph-web