On 01/05/2017 11:27 AM, Michal Hocko wrote: > On Thu 05-01-17 10:53:59, Vlastimil Babka wrote: >>>> Therefore I believe we need a watermark based pro-active compaction >>>> which would keep the background compaction busy as long as we have >>>> less pages of the configured order. >> >> Again, configured by what, admin? I would rather try to avoid tunables >> here, if possible. While THP is quite well known example with stable >> order, the pressure for other orders is rather implementation specific >> (drivers, SLAB/SLUB) and may change with kernel versions (e.g. virtually >> mapped stacks, although that example is about non-costly order). Would >> the admin be expected to study the implementation to know which orders >> are needed, or react to page allocation failure reports? Neither sounds >> nice. > > That is a good question but I expect that there are more users than THP > which use stable orders. E.g. networking stack tends to depend on the > packet size. A tracepoint with some histogram output would tell us what > is the requested orders distribution. Maybe, but there might be also multiple users of the same order but different "importance"... >>>> kcompactd should wake up >>>> periodically, I think, and check for the status so that we can catch >>>> the fragmentation before we get low on memory. >>>> The interface could look something like: >>>> /proc/sys/vm/compact_wmark >>>> time_period order count >> >> IMHO it would be better if the system could auto-tune this, e.g. by >> counting high-order alloc failures/needs for direct compaction per order >> between wakeups, and trying to bring them to zero. > > auto-tunning is usually preferable I am just wondering how the admin can > tell what is still the system load price he is willing to pay. I suspect > we will see growing number of opportunistic high order requests over > time and auto tunning shouldn't try to accomodate with it without > any bounds.There is still some cost/benefit to be evaluated from the > system level point of view which I am afraid is hard to achive from the > kcompactd POV. That's why I mentioned that importance should be judged somehow. Opportunistic requests should be recognizable by their gfp flags, so hopefully there's a way. I wouldn't mind some general tunable(s) to express how much effort to give to "important" allocations and opportunistic ones, but rather not in such implementation-detail form as "time_period order count". -- 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>