On Mon, Jul 22, 2013 at 07:01:18PM -0700, PINTU KUMAR wrote: > >Lastly, order >= MAX_ORDER is not supported by the page allocator, and > >we do not want to punish 99.999% of all legitimate page allocations in > >the fast path in order to catch an unlikely situation like this. [...] > >Having the check only in the slowpath is a good thing. > > > Sorry, I could not understand, why adding this check in slowpath is only good. > We could have returned failure much before that. > Without this check, we are actually allowing failure of "first allocation attempt" and then returning the cause of failure in slowpath. > I thought it will be better to track the unlikely failure in the system as early as possible, at least from the embedded system prospective. > Let me know your opinion. This is a trade-off between two cases: we expect (almost) all allocations to be order < MAX_ORDER, so we want that path as lightweight as possible. On the other hand, we expect that only very rarely an allocation will specify order >= MAX_ORDER. By doing the check late, we make the common case faster at the expense of the rare case. That's the whole point of having a fast path and a slow path. What you are proposing would punish 99.999% of all cases in order to speed up the 0.001% cases. In addition, these 0.001% of all cases will fail the allocation, so performance is the least of their worries. It's a bad trade-off. -- 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>