On Tue, Aug 27, 2024 at 08:49:35AM +0200, Michal Hocko wrote:
> On Mon 26-08-24 14:38:40, Uladzislau Rezki wrote:
> > On Mon, Aug 26, 2024 at 09:52:42AM +0200, Michal Hocko wrote:
> > > On Fri 23-08-24 18:42:47, Uladzislau Rezki wrote:
> > > [...]
> > > > @@ -3666,7 +3655,16 @@ static void *__vmalloc_area_node(struct vm_struct *area, gfp_t gfp_mask,
> > > > set_vm_area_page_order(area, page_shift - PAGE_SHIFT);
> > > > page_order = vm_area_page_order(area);
> > > >
> > > > - area->nr_pages = vm_area_alloc_pages(gfp_mask | __GFP_NOWARN,
> > > > + /*
> > > > + * Higher order nofail allocations are really expensive and
> > > > + * potentially dangerous (pre-mature OOM, disruptive reclaim
> > > > + * and compaction etc.
> > > > + *
> > > > + * Please note, the __vmalloc_node_range_noprof() falls-back
> > > > + * to order-0 pages if high-order attempt has been unsuccessful.
> > > > + */
> > > > + area->nr_pages = vm_area_alloc_pages(page_order ?
> > > > + gfp_mask &= ~__GFP_NOFAIL : gfp_mask | __GFP_NOWARN,
> > > > node, page_order, nr_small_pages, area->pages);
> > > >
> > > > atomic_long_add(area->nr_pages, &nr_vmalloc_pages);
> > > > <snip>
> > > >
> > > > Is that aligned with your wish?
> > >
> > > I am not a great fan of modifying gfp_mask inside the ternary operator
> > > like that. It makes the code harder to read. Is there any actual reason
> > > to simply drop GFP_NOFAIL unconditionally and rely do the NOFAIL
> > > handling for all orders at the same place?
> > >
> > 1. So, for bulk we have below:
> >
> > /* gfp_t bulk_gfp = gfp & ~__GFP_NOFAIL; */
> >
> > I am not sure if we need it but it says it does not support it which
> > is not clear for me why we have to drop __GFP_NOFAIL for bulk(). There
> > is a fallback to a single page allocator. If passing __GFP_NOFAIL does
> > not trigger any warning or panic a system, then i do not follow why
> > we drop that flag.
> >
> > Is that odd?
>
> I suspect this was a pre-caution more than anything.
>
OK, then i drop it.
> > 2. High-order allocations. Do you think we should not care much about
> > it when __GFP_NOFAIL is set? Same here, there is a fallback for order-0
> > if "high" fails, it is more likely NO_FAIL succeed for order-0. Thus
> > keeping NOFAIL for high-order sounds like not a good approach to me.
>
> We should avoid high order allocations with GFP_NOFAIL at all cost.
>
What do you propose here? Fail such request?
> > 3. "... at the same place?"
> > Do you mean in the __vmalloc_node_range_noprof()?
> >
> > __vmalloc_node_range_noprof()
> > -> __vmalloc_area_node(gfp_mask)
> > -> vm_area_alloc_pages()
> >
> > if, so it is not straight forward, i.e. there is one more allocation:
> >
> > <snip>
> > static void *__vmalloc_area_node(struct vm_struct *area, gfp_t gfp_mask,
> > pgprot_t prot, unsigned int page_shift,
> > int node)
> > {
> > ...
> > /* Please note that the recursion is strictly bounded. */
> > if (array_size > PAGE_SIZE) {
> > area->pages = __vmalloc_node_noprof(array_size, 1, nested_gfp, node,
> > area->caller);
> > } else {
> > area->pages = kmalloc_node_noprof(array_size, nested_gfp, node);
> > }
> > ...
> > }
> > <snip>
> >
> > whereas it is easier to do it inside of the __vmalloc_area_node().
>
> Right. The allocation path is quite convoluted here. If it is just too
> much of a hassle to implement NOFAIL at a single place then we should
> aim at reducing that. Having that at 3 different layers is just begging
> for inconsistences.
>
Hard to not agree :)
--
Uladzislau Rezki
