On Tue 23-08-16 15:08:05, Linus Torvalds wrote: > On Tue, Aug 23, 2016 at 3:33 AM, Michal Hocko <mhocko@xxxxxxxxxx> wrote: > > > > I would argue that CONFIG_COMPACTION=n behaves so arbitrary for high > > order workloads that calling any change in that behavior a regression > > is little bit exaggerated. > > Well, the thread info allocations certainly haven't been big problems > before. So regressing those would seem to be a real regression. > > What happened? We've done the order-2 allocation for the stack since > May 2014, so that isn't new. Did we cut off retries for low orders? Yes, with the original implementation the number of reclaim retries is basically unbounded and as long as we have a reclaim progress. This has changed to be a bounded process. Without the compaction this means that we were reclaim as long as an order-2 page was formed. > So I would not say that it's an exaggeration to say that order-2 > allocations failing is a regression. I would agree with you with COMPACTION enabled but with compaction disabled which should be really limited to !MMU configurations I think there is not much we can do. Well, we could simply retry for ever without invoking OOM killer for higher order request for this config option and rely on order-0 to hit the OOM. Do we want that though? I do not remember anybody with !MMU to complain. Markus had COMPACTION disabled accidentally. -- Michal Hocko 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>