From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754344AbeDITjK (ORCPT ); Mon, 9 Apr 2018 15:39:10 -0400 Received: from mx2.suse.de ([195.135.220.15]:48757 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754240AbeDITjI (ORCPT ); Mon, 9 Apr 2018 15:39:08 -0400 Date: Mon, 09 Apr 2018 21:39:06 +0200 Message-ID: From: Takashi Iwai To: "Pierre-Louis Bossart" Cc: , "Jia-Ju Bai" , , , , , , "Vinod Koul" , Subject: Re: [alsa-devel] [PATCH] sound: soc: intel: bxt_da7219_max98357a: Replace GFP_ATOMIC with GFP_KERNEL in broxton_audio_probe In-Reply-To: <482591fb-bf12-2e0a-e0ef-2ae0b4095000@linux.intel.com> References: <1523270781-22627-1-git-send-email-baijiaju1990@gmail.com> <482591fb-bf12-2e0a-e0ef-2ae0b4095000@linux.intel.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI/1.14.6 (Maruoka) FLIM/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL/10.8 Emacs/25.3 (x86_64-suse-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, 09 Apr 2018 20:57:43 +0200, Pierre-Louis Bossart wrote: > > On 4/9/18 5:46 AM, Jia-Ju Bai wrote: > > broxton_audio_probe() is never called in atomic context. > > This function is only set as ".probe" in "struct platform_driver". > > > > Despite never getting called from atomic context, > > broxton_audio_probe() calls devm_kzalloc() with GFP_ATOMIC, > > which waits busily for allocation. > > GFP_ATOMIC is not necessary and can be replaced with GFP_KERNEL, > > to avoid busy waiting and improve the possibility of sucessful allocation. > > [answering for the series] > Humm, this is interesting. > If indeed we can afford to sleep then the change should be done on ALL > 14 boards in sound/soc/intel/boards which follow the same code > pattern. > If we cannot sleep then then none of these changes should be applied. > Liam and Vinod? It must be sleepable context as it's a standard platform driver probe callback. And now looking at grep output, only sound/soc/intel contains so many calls with GFP_ATOMIC. I bet that almost all can be done with GFP_KERNEL, maybe only one or two in atom/sst would be conditionally with GFP_ATOMIC. thanks, Takashi From mboxrd@z Thu Jan 1 00:00:00 1970 From: Takashi Iwai Subject: Re: [alsa-devel] [PATCH] sound: soc: intel: bxt_da7219_max98357a: Replace GFP_ATOMIC with GFP_KERNEL in broxton_audio_probe Date: Mon, 09 Apr 2018 21:39:06 +0200 Message-ID: References: <1523270781-22627-1-git-send-email-baijiaju1990@gmail.com> <482591fb-bf12-2e0a-e0ef-2ae0b4095000@linux.intel.com> Mime-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Return-path: In-Reply-To: <482591fb-bf12-2e0a-e0ef-2ae0b4095000@linux.intel.com> Sender: linux-kernel-owner@vger.kernel.org To: Pierre-Louis Bossart Cc: Adam.Thomson.Opensource@diasemi.com, Jia-Ju Bai , lgirdwood@gmail.com, sathyanarayana.nujella@intel.com, broonie@kernel.org, perex@perex.cz, alsa-devel@alsa-project.org, Vinod Koul , linux-kernel@vger.kernel.org List-Id: alsa-devel@alsa-project.org On Mon, 09 Apr 2018 20:57:43 +0200, Pierre-Louis Bossart wrote: > > On 4/9/18 5:46 AM, Jia-Ju Bai wrote: > > broxton_audio_probe() is never called in atomic context. > > This function is only set as ".probe" in "struct platform_driver". > > > > Despite never getting called from atomic context, > > broxton_audio_probe() calls devm_kzalloc() with GFP_ATOMIC, > > which waits busily for allocation. > > GFP_ATOMIC is not necessary and can be replaced with GFP_KERNEL, > > to avoid busy waiting and improve the possibility of sucessful allocation. > > [answering for the series] > Humm, this is interesting. > If indeed we can afford to sleep then the change should be done on ALL > 14 boards in sound/soc/intel/boards which follow the same code > pattern. > If we cannot sleep then then none of these changes should be applied. > Liam and Vinod? It must be sleepable context as it's a standard platform driver probe callback. And now looking at grep output, only sound/soc/intel contains so many calls with GFP_ATOMIC. I bet that almost all can be done with GFP_KERNEL, maybe only one or two in atom/sst would be conditionally with GFP_ATOMIC. thanks, Takashi