Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753268Ab2JPFtz (ORCPT ); Tue, 16 Oct 2012 01:49:55 -0400 Received: from mail-pa0-f46.google.com ([209.85.220.46]:61321 "EHLO mail-pa0-f46.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751317Ab2JPFtx (ORCPT ); Tue, 16 Oct 2012 01:49:53 -0400 Date: Tue, 16 Oct 2012 14:49:46 +0900 From: Minchan Kim To: Ming Lei Cc: linux-kernel@vger.kernel.org, Greg Kroah-Hartman , linux-usb@vger.kernel.org, linux-pm@vger.kernel.org, Alan Stern , Oliver Neukum , Jiri Kosina , Andrew Morton , Mel Gorman , KAMEZAWA Hiroyuki , Michal Hocko , Ingo Molnar , Peter Zijlstra , "Rafael J. Wysocki" , linux-mm Subject: Re: [RFC PATCH 1/3] mm: teach mm by current context info to not do I/O during memory allocation Message-ID: <20121016054946.GA3934@barrios> References: <1350278059-14904-1-git-send-email-ming.lei@canonical.com> <1350278059-14904-2-git-send-email-ming.lei@canonical.com> <20121015154724.GA2840@barrios> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3496 Lines: 75 On Tue, Oct 16, 2012 at 09:56:48AM +0800, Ming Lei wrote: > On Mon, Oct 15, 2012 at 11:47 PM, Minchan Kim wrote: > > On Mon, Oct 15, 2012 at 01:14:17PM +0800, Ming Lei wrote: > >> This patch introduces PF_MEMALLOC_NOIO on process flag('flags' field of > >> 'struct task_struct'), so that the flag can be set by one task > >> to avoid doing I/O inside memory allocation in the task's context. > >> > >> The patch trys to solve one deadlock problem caused by block device, > >> and the problem can be occured at least in the below situations: > >> > >> - during block device runtime resume situation, if memory allocation > >> with GFP_KERNEL is called inside runtime resume callback of any one > >> of its ancestors(or the block device itself), the deadlock may be > >> triggered inside the memory allocation since it might not complete > >> until the block device becomes active and the involed page I/O finishes. > >> The situation is pointed out first by Alan Stern. It is not a good > >> approach to convert all GFP_KERNEL in the path into GFP_NOIO because > >> several subsystems may be involved(for example, PCI, USB and SCSI may > >> be involved for usb mass stoarage device) > > > > Couldn't we expand pm_restrict_gfp_mask to cover resume path as well as > > suspend path? > > IMO, we could, but it is not good and might trigger memory allocation problem. > > pm_restrict_gfp_mask uses the global variable of gfp_allowed_mask to > avoid allocating page with GFP_IOFS in all contexts during system sleep, > when processes have been frozen. > > But during runtime PM, the whole system is running and all processes are > runnable. Also runtime PM is per device and the whole system may have > lots of devices, so taking the global gfp_allowed_mask may keep page > allocation with ~GFP_IOFS for a considerable proportion of system > running time, then alloc_page() will return failure easier. > > The above deadlock problem may be fixed by allocating memory with > ~GFP_IOFS only in the context of calling runtime_resume, and that is > idea of the patch. Fair enough but it wouldn't be a good idea that add new unlikely branch in allocator's fast path. Please move the check into slow path which could be in __alloc_pages_slowpath. > > > > >> > >> - during error handling situation of usb mass storage deivce, USB > >> bus reset will be put on the device, so there shouldn't have any > >> memory allocation with GFP_KERNEL during USB bus reset, otherwise > >> the deadlock similar with above may be triggered. Unfortunately, any > >> usb device may include one mass storage interface in theory, so it > >> requires all usb interface drivers to handle the situation. In fact, > >> most usb drivers don't know how to handle bus reset on the device > >> and don't provide .pre_set() and .post_reset() callback at all, so > >> USB core has to unbind and bind driver for these devices. So it > >> is still not practical to resort to GFP_NOIO for solving the problem. > > > > I hope this case could be handled by usb core like usb_restrict_gfp_mask > > rather than adding new branch on fast path. > > See above, applying the global gfp_allowed_mask is not good. > > > Thanks, > -- > Ming Lei -- Kind Regards, Minchan Kim -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/