From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752021AbcACQ4T (ORCPT ); Sun, 3 Jan 2016 11:56:19 -0500 Received: from zeniv.linux.org.uk ([195.92.253.2]:44551 "EHLO ZenIV.linux.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750952AbcACQ4Q (ORCPT ); Sun, 3 Jan 2016 11:56:16 -0500 Date: Sun, 3 Jan 2016 16:56:13 +0000 From: Al Viro To: linux-mm@kvack.org Cc: linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, Dave Chinner , Ming Lei Subject: Re: __vmalloc() vs. GFP_NOIO/GFP_NOFS Message-ID: <20160103165613.GL9938@ZenIV.linux.org.uk> References: <20160103071246.GK9938@ZenIV.linux.org.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160103071246.GK9938@ZenIV.linux.org.uk> 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 On Sun, Jan 03, 2016 at 07:12:47AM +0000, Al Viro wrote: > Allocation page tables doesn't have gfp argument at all. Trying to propagate > it down there could be done, but it's not attractive. While we are at it, is there ever a reason to _not_ pass __GFP_HIGHMEM in __vmalloc() flags? After all, we explicitly put the pages we'd allocated into the page table at vmalloc range we'd grabbed and these are the addresses visible to caller. Is there any point in having another alias for those pages? vmalloc() itself passes __GFP_HIGHMEM and so does a lot of __vmalloc() callers; in fact, most of those that do not look like a result of "we want vmalloc(), but we want to avoid it going into fs code and possibly deadlocking us; vmalloc() has no gfp_t argument, so let's use __vmalloc() and give it GFP_NOFS". Another very weird thing is the use of GFP_ATOMIC by alloc_large_system_hash(); if we want _that_ honoured, we'd probably have to pass gfp_t to alloc_one_pmd() and friends, but I'm not sure what exactly is that caller requesting. Confused... From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Date: Sun, 3 Jan 2016 16:56:13 +0000 From: Al Viro To: linux-mm@kvack.org Cc: linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, Dave Chinner , Ming Lei Subject: Re: __vmalloc() vs. GFP_NOIO/GFP_NOFS Message-ID: <20160103165613.GL9938@ZenIV.linux.org.uk> References: <20160103071246.GK9938@ZenIV.linux.org.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160103071246.GK9938@ZenIV.linux.org.uk> Sender: owner-linux-mm@kvack.org List-ID: On Sun, Jan 03, 2016 at 07:12:47AM +0000, Al Viro wrote: > Allocation page tables doesn't have gfp argument at all. Trying to propagate > it down there could be done, but it's not attractive. While we are at it, is there ever a reason to _not_ pass __GFP_HIGHMEM in __vmalloc() flags? After all, we explicitly put the pages we'd allocated into the page table at vmalloc range we'd grabbed and these are the addresses visible to caller. Is there any point in having another alias for those pages? vmalloc() itself passes __GFP_HIGHMEM and so does a lot of __vmalloc() callers; in fact, most of those that do not look like a result of "we want vmalloc(), but we want to avoid it going into fs code and possibly deadlocking us; vmalloc() has no gfp_t argument, so let's use __vmalloc() and give it GFP_NOFS". Another very weird thing is the use of GFP_ATOMIC by alloc_large_system_hash(); if we want _that_ honoured, we'd probably have to pass gfp_t to alloc_one_pmd() and friends, but I'm not sure what exactly is that caller requesting. Confused... -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org