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 from this list: send the line "unsubscribe linux-api" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
