Re: [PATCH 1/2] Protect larger order pages from breaking up

[Christopher Lameter <cl@linux.com>]

On Mon, 26 Feb 2018, Vlastimil Babka wrote:

> > 	echo "3=2000" >/proc/zoneinfo
>
> Huh, that's rather weird interface to use. Writing to a general
> statistics/info file for such specific functionality? Please no.

Ok lets create /proc/sys/kernel/orders?\

Or put it into /sys/devices/syste/node/nodeX/orders

?

> > First performance tests in a virtual enviroment show
> > a hackbench improvement by 6% just by increasing
> > the page size used by the page allocator.
>
> That's IMHO a rather weak justification for introducing a new userspace
> API. What exactly has been set where? Could similar results be achieved
> by tuning highatomic reservers and/or min_free_kbytes? I especially
> wonder how much of the effects come from the associated watermarks
> adjustment (which can be affected by min_free_kbytes) and what is due to
> __rmqueue_smallest() changes. You changed the __rmqueue_smallest()
> condition since RFC per Thomas suggestion, but report the same results?

The highatomic reserves are for temporary allocations for jumbo frames.
The allocations here could be for numerous purposes.

The test demonstrates a performance gain by the user of higher order
pages. It does not demonstrate long term fragmentation results. For that
different benchmarks would have to be used. Maybe I can find something in
Mel's tests to get that tested.

Such test would have to verify that the system holds up despite large
order allocation. It would not demonstrate a performance benefit. However,
what we want is the performance benefit throughout the operation of the
system. So both tests are required.


> Well, also not a fan of this patch, TBH. It's rather ad-hoc and not
> backed up with results. Aside from the above points, I agree with the
> objections of others for the RFC posting. It's also rather awkward that
> watermarks are increased per the reservations, but when the reservations
> are "consumed" (nr_free < min && current_order == order), the increased
> watermarks are untouched. IMHO this further enlarges the effects of
> purely adjusted watermarks by this patch.

This is an RFC to see where we could do with this. I am looking for ways
to address the various shortcomings of this approach. There are others
approaches that have similar effects and that may be more desirable but
require more work (such as making dentries/inodes defragmentable via
migration or targeted reclaim).


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