Re: [RFC] kswapd aggressiveness with watermark_scale_factor

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

 



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.

-- 
Mel Gorman
SUSE Labs

--
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