Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752159AbdCCTZx (ORCPT ); Fri, 3 Mar 2017 14:25:53 -0500 Received: from mail-pg0-f65.google.com ([74.125.83.65]:36729 "EHLO mail-pg0-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752348AbdCCTZu (ORCPT ); Fri, 3 Mar 2017 14:25:50 -0500 Date: Fri, 3 Mar 2017 11:23:25 -0800 From: Tejun Heo To: Tahsin Erdogan Cc: Jens Axboe , linux-block@vger.kernel.org, David Rientjes , linux-kernel@vger.kernel.org Subject: Re: [PATCH v2] blkcg: allocate struct blkcg_gq outside request queue spinlock Message-ID: <20170303192325.GB22962@wtj.duckdns.org> References: <20170301165501.GB3662@htj.duckdns.org> <20170301234319.29584-1-tahsin@google.com> <20170302193205.GB8519@wtj.duckdns.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.7.1 (2016-10-04) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 928 Lines: 27 Hello, Tahsin. On Thu, Mar 02, 2017 at 02:33:11PM -0800, Tahsin Erdogan wrote: > > And let blkg_create() verify these conditions after releasing and > > regrabbing the lock. > > > > This also means that the init path can simply pass in GFP_KERNEL. > > I tried that approach, but I encountered two issues that complicate things: > > 1) Pushing down blk_queue_bypass(q) check in blkg_create() doesn't > quite work because when blkcg_init_queue() calls blkg_create(), the > queue is still in bypassing mode. > > 2) Pushing down blkcg_policy_enabled() doesn't work well either, > because blkcg_init_queue() doesn't have a policy to pass down. We > could let it pass a NULL parameter but that would make blkg_create > more ugly. I see. It kinda really bothers me that we'll have two different modes for non-atomic allocations. Can't we bind both to the policy parameter? Skip the checks if policy is NULL? Thanks. -- tejun