On 2 Feb 2018, at 17:47, Mel Gorman wrote:
> On Fri, Feb 02, 2018 at 02:16:39PM +0000, Robert Harris wrote:
>> I was planning to annotate the opaque calculation in
>> __fragmentation_index() but on closer inspection I think there may be a
>> bug. I could use some feedback.
> On 19 Feb 2018, at 12:39, Michal Hocko wrote:
>
> On Mon 19-02-18 12:14:26, Robert Harris wrote:
>>
>>
>>> On 19 Feb 2018, at 08:26, Michal Hocko wrote:
>>>
>>> On Sun 18-02-18 16:47:55, robert.m.har...@oracle.com wrote:
>>>>
> On 23 Feb 2018, at 09:10, Michal Hocko wrote:
>
> On Mon 19-02-18 14:30:36, Robert Harris wrote:
>>
>>
>>> On 19 Feb 2018, at 12:39, Michal Hocko wrote:
>>>
>>> On Mon 19-02-18 12:14:26, Robert Harris wrote:
>>>>
>>>&g
n is one of cost but, as compaction is linear, this isn't
what __fragmentation_index() is calculating. A more reasonable argument
is that there's generally some lower limit on the fragmentation
achievable through compaction, given the inevitable presence of
non-migratable pages. Is there anything else going on?
Robert Harris
hanging 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 pressure.
Robert Harris
uld 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 even for non-zero fragmentation during
an extreme shortage of memory
?
Robert Harris
> On 19 Feb 2018, at 13:10, Mel Gorman wrote:
>
> On Mon, Feb 19, 2018 at 12:26:39PM +0000, Robert Harris wrote:
>>
>>
>>> On 19 Feb 2018, at 09:47, Mel Gorman wrote:
>>>
>>> On Sun, Feb 18, 2018 at 04:47:55PM +, robert.m.har..
7 matches
Mail list logo
