> 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
> 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 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..
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
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
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.
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
7 matches
Mail list logo
