On Thu, Aug 22, 2024 at 05:53:22PM +0800, Linus Torvalds wrote: > On Thu, 22 Aug 2024 at 17:43, David Hildenbrand <david@xxxxxxxxxx> wrote: > > > > So on the buddy level, that might mean that we limit it to a single > > page, > > Actually, for many SLUB allocations, you probably do have to accept > the small orders - the slab caches are often two or four pages. > > For example, a kmalloc(256) is an order-1 allocation on a buddy level > from a quick look at /proc/slabinfo. It will try higher orders to reduce fragmentation (and mask out NOFAIL on those attempts), but it can fall back to the minimum size required for the object, i.e. get_order(size). > So it's not necessarily only single pages. We do handle small orders. > But it gets exponentially harder, so it really is just the small > orders that work. Agreed. > Looks like slub will use up to order-3. That smells like an off-by-one > to me (I thought we made 0-2 be the "cheap" orders, but maybe I'm just > wrong), but it probably is still acceptable. It's 0-3. We #define PAGE_ALLOC_COSTLY_ORDER 3, but it's exclusive - all the order checks are > costly and <= costly.
