From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751740AbdJRVpQ (ORCPT ); Wed, 18 Oct 2017 17:45:16 -0400 Received: from mail-qt0-f171.google.com ([209.85.216.171]:54375 "EHLO mail-qt0-f171.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750853AbdJRVpP (ORCPT ); Wed, 18 Oct 2017 17:45:15 -0400 X-Google-Smtp-Source: ABhQp+RxlCxsJZaqJcuCpXDEVmL+H7+VMi31snYf3y0JTJibzOXs+wGWgJJ/bYVojDP7OwC72xSFkw== Date: Wed, 18 Oct 2017 16:45:08 -0500 From: Dennis Zhou To: Tejun Heo Cc: Daniel Borkmann , davem@davemloft.net, ast@kernel.org, john.fastabend@gmail.com, mark.rutland@arm.com, richard@nod.at, sp3485@columbia.edu, netdev@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH net 0/3] Fix for BPF devmap percpu allocation splat Message-ID: <20171018214508.GA12295@localhost.corp.microsoft.com> References: <20171018132526.GC1302522@devbig577.frc2.facebook.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20171018132526.GC1302522@devbig577.frc2.facebook.com> User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Daniel and Tejun, On Wed, Oct 18, 2017 at 06:25:26AM -0700, Tejun Heo wrote: > > Daniel Borkmann (3): > > mm, percpu: add support for __GFP_NOWARN flag > > This looks fine. > Looks good to me too. > > bpf: fix splat for illegal devmap percpu allocation > > bpf: do not test for PCPU_MIN_UNIT_SIZE before percpu allocations > > These look okay too but if it helps percpu allocator can expose the > maximum size / alignment supported to take out the guessing game too. > I can add this once we've addressed the below if we want to. > Also, the reason why PCPU_MIN_UNIT_SIZE is what it is is because > nobody needed anything bigger. Increasing the size doesn't really > cost much at least on 64bit archs. Is that something we want to be > considering? > I'm not sure I see the reason we can't match the minimum allocation size with the unit size? It seems weird to arbitrate the maximum allocation size given a lower bound on the unit size. Thanks, Dennis