On Fri, 2024-02-02 at 10:10 +0800, Yunsheng Lin wrote: > On 2024/2/1 21:16, Paolo Abeni wrote: > > > from the __page_frag_cache_refill() allocator - which never accesses > > the memory reserves. > > I am not really sure I understand the above commemt. > The semantic is the same as skb_page_frag_refill() as explained above > as my understanding. Note that __page_frag_cache_refill() use 'gfp_mask' > for allocating order 3 pages and use the original 'gfp' for allocating > order 0 pages. You are right! I got fooled misreading 'gfp' as 'gfp_mask' in there. > > I'm unsure we want to propagate the __page_frag_cache_refill behavior > > here, the current behavior could be required by some systems. > > > > It looks like this series still leave the skb_page_frag_refill() > > allocator alone, what about dropping this chunk, too? > > As explained above, I would prefer to keep it as it is as it seems > to be quite obvious that we can avoid possible pressure for mm by > not using memory reserve for order 3 pages as we have the fallback > for order 0 pages. > > Please let me know if there is anything obvious I missed. > I still think/fear that behaviours changes here could have subtle/negative side effects - even if I agree the change looks safe. I think the series without this patch would still achieve its goals and would be much more uncontroversial. What about move this patch as a standalone follow-up? Thanks! Paolo
