Re: [RFC] kswapd aggressiveness with watermark_scale_factor

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 3/7/2018 3:48 PM, Mel Gorman wrote:
> On Wed, Mar 07, 2018 at 02:47:09PM +0530, Vinayak Menon wrote:
>>> This needs a proper changelog, signed-offs and a comment on the reasoning
>>> behind the new min value for the gap between low and high and how it
>>> was derived.  It appears the equation was designed such at the gap, as
>>> a percentage of the zone size, would shrink according as the zone size
>>> increases but I'm not 100% certain that was the intent. That should be
>>> explained and why not just using "tmp >> 2" would have problems.
>>>
>>> It would also need review/testing by Johannes to ensure that there is no
>>> reintroduction of the problems that watermark_scale_factor was designed
>>> to solve.
>> Sorry for the delayed response. I will send a patch with the details. The equation was designed so that the
>> low-high gap is small for smaller RAM sizes and tends towards min-low gap as the RAM size increases. This
>> was done considering that it should not have a bad effect on for 140G configuration which Johannes had taken
>> taken as example when watermark_scale_factor was introduced, also assuming that the thrashing seen due to
>> low-high gap would be visible only on low RAM devices.
>>
> If you do spin a new version with corrections made, be very careful to
> note that the figures you supply are based on a kernel without THP because
> that's where it makes a real difference. The differences with THP enabled
> are very different as that alters min_free_kbytes and by extention, it
> changes the point where your patch has an effect on the distance between
> watermarks. It does mean that a test you say definitely works will not
> necessary be visible to someone who tests the same patch on x86-64. Maybe
> no one will notice or care but if you get a report about the results being
> unreproducible then I suggest you check first if THP was enabled.

Sure. The results provided earlier were without THP.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@xxxxxxxxx.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>



[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux