Re: [PATCH 1/1] mm, compaction: correct the bounds of __fragmentation_index()

2018-02-23 Thread Robert Harris
> On 23 Feb 2018, at 09:10, Michal Hocko <mho...@kernel.org> wrote: > > On Mon 19-02-18 14:30:36, Robert Harris wrote: >> >> >>> On 19 Feb 2018, at 12:39, Michal Hocko <mho...@kernel.org> wrote: >>> >>> On Mon 19-02-18 12:14:26, Rob

Re: [PATCH 1/1] mm, compaction: correct the bounds of __fragmentation_index()

2018-02-22 Thread Robert Harris
> On 19 Feb 2018, at 12:39, Michal Hocko <mho...@kernel.org> wrote: > > On Mon 19-02-18 12:14:26, Robert Harris wrote: >> >> >>> On 19 Feb 2018, at 08:26, Michal Hocko <mho...@kernel.org> wrote: >>> >>> On Sun 18-02-18 16:47:55, ro

Re: [PATCH 1/1] mm, compaction: correct the bounds of __fragmentation_index()

2018-02-19 Thread Robert Harris
> On 19 Feb 2018, at 13:10, Mel Gorman <mgor...@suse.de> wrote: > > On Mon, Feb 19, 2018 at 12:26:39PM +, Robert Harris wrote: >> >> >>> On 19 Feb 2018, at 09:47, Mel Gorman <mgor...@suse.de> wrote: >>> >>> On Sun, Feb 18

Re: [PATCH 1/1] mm, compaction: correct the bounds of __fragmentation_index()

2018-02-19 Thread Robert Harris
already and adjusting > that default should be supported by data indicating it's safe. Would it be acceptable to demonstrate using tracing that in both the pre- and post-patch cases 1. compaction is attempted regardless of fragmentation index, excepting that 2. reclaim is preferred

Re: [PATCH 1/1] mm, compaction: correct the bounds of __fragmentation_index()

2018-02-19 Thread Robert Harris
eaning that the existing behaviour will be unchanged. Changing sysctl_extfrag_threshold back to something non-zero in a future patch would effect the behaviour intended by the original code but would require more comprehensive testing since it would modify the kernel's performance under memory press