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