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

Groups > linux.kernel > #1602762 > unrolled thread

Re: [PATCH v3 0/8] try to reduce fragmenting fallbacks

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCH v3 0/8] try to reduce fragmenting fallbacks Johannes Weiner <hannes@cmpxchg.org> - 2017-03-16 19:40 +0100
    Re: [PATCH v3 0/8] try to reduce fragmenting fallbacks Vlastimil Babka <vbabka@suse.cz> - 2017-03-17 19:40 +0100
      Re: [PATCH v3 0/8] try to reduce fragmenting fallbacks Johannes Weiner <hannes@cmpxchg.org> - 2017-03-19 22:30 +0100

#1602762 — Re: [PATCH v3 0/8] try to reduce fragmenting fallbacks

On Wed, Mar 08, 2017 at 08:17:39PM +0100, Vlastimil Babka wrote:
> On 8.3.2017 17:46, Johannes Weiner wrote:
> > Is there any other data you would like me to gather?
> 
> If you can enable the extfrag tracepoint, it would be nice to have graphs of how
> unmovable allocations falling back to movable pageblocks, etc.

Okay, here we go. I recorded 24 hours worth of the extfrag tracepoint,
filtered to fallbacks from unmovable requests to movable blocks. I've
uploaded the plot here:

http://cmpxchg.org/antifrag/fallbackrate.png

but this already speaks for itself:

11G     alloc-mtfallback.trace
3.3G    alloc-mtfallback-patched.trace

;)

> Possibly also /proc/pagetypeinfo for numbers of pageblock types.

After a week of uptime, the patched (b) kernel has more movable blocks
than vanilla 4.10-rc8 (a):

   Number of blocks type     Unmovable      Movable  Reclaimable   HighAtomic          CMA      Isolate

a: Node 1, zone   Normal         2017        29763          987            1            0            0
b: Node 1, zone   Normal         1264        30850          653            1            0            0

I sampled this somewhat sporadically over the week and it's been
reading reliably this way.

The patched kernel also consistently beats vanilla in terms of peak
job throughput.

Overall very cool!

[toc] | [next] | [standalone]

#1603540

On 03/16/2017 07:34 PM, Johannes Weiner wrote:
> On Wed, Mar 08, 2017 at 08:17:39PM +0100, Vlastimil Babka wrote:
>> On 8.3.2017 17:46, Johannes Weiner wrote:
>>> Is there any other data you would like me to gather?
>>
>> If you can enable the extfrag tracepoint, it would be nice to have graphs of how
>> unmovable allocations falling back to movable pageblocks, etc.
> 
> Okay, here we go. I recorded 24 hours worth of the extfrag tracepoint,
> filtered to fallbacks from unmovable requests to movable blocks. I've
> uploaded the plot here:
> 
> http://cmpxchg.org/antifrag/fallbackrate.png
> 
> but this already speaks for itself:
> 
> 11G     alloc-mtfallback.trace
> 3.3G    alloc-mtfallback-patched.trace
> 
> ;)

Great!

>> Possibly also /proc/pagetypeinfo for numbers of pageblock types.

> After a week of uptime, the patched (b) kernel has more movable blocks
> than vanilla 4.10-rc8 (a):
> 
>    Number of blocks type     Unmovable      Movable  Reclaimable   HighAtomic          CMA      Isolate
> 
> a: Node 1, zone   Normal         2017        29763          987            1            0            0
> b: Node 1, zone   Normal         1264        30850          653            1            0            0

That's better than I expected. I wouldn't be surprised if the number of
unmovable pageblocks actually got *higher* due to the series because
previously many unmovable pages would be scattered around movable blocks.

> I sampled this somewhat sporadically over the week and it's been
> reading reliably this way.
> 
> The patched kernel also consistently beats vanilla in terms of peak
> job throughput.
> 
> Overall very cool!

Thanks a lot! So that means it's worth the increased compaction stats
you reported earlier?

[toc] | [prev] | [next] | [standalone]

#1604091

On Fri, Mar 17, 2017 at 07:29:54PM +0100, Vlastimil Babka wrote:
> On 03/16/2017 07:34 PM, Johannes Weiner wrote:
> > The patched kernel also consistently beats vanilla in terms of peak
> > job throughput.
> > 
> > Overall very cool!
> 
> Thanks a lot! So that means it's worth the increased compaction stats
> you reported earlier?

Yes, from the impact this patchset has on the workload overall, I'm
assuming that the increased work pays off.

So maybe something to keep an eye out for, but IMO not a dealbreaker.

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web