On 08/09/16 at 02:22pm, Florian Westphal wrote: > Hmmm, seems this is coming from an attempt to allocate the bucket lock > array (since actual table has __GFP_NOWARN). > > I was about to just send a patch that adds a GPF_NOWARN in > bucket_table_alloc/alloc_bucket_locks call. > > However, I wonder if we really need this elaborate sizing logic. > I think it makes more sense to always allocate a fixed size regardless > of number of CPUs, i.e. get rid of locks_mul and all the code that comes > with it. > > Doing order-3 allocation for locks seems excessive to me. > > The netfilter conntrack hashtable just uses a fixed array of 1024 > spinlocks (so on x86_64 we get on page of locks). > > What do you think? The code has been primarily derived from inet_ehash_locks_alloc() so my initial suggestion would be to adjust it to after Eric's latest fixes including the change to GFP_NOWARN. -- To unsubscribe from this list: send the line "unsubscribe netfilter" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
