From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756584AbcG0OJo (ORCPT ); Wed, 27 Jul 2016 10:09:44 -0400 Received: from mx1.redhat.com ([209.132.183.28]:51442 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756460AbcG0OJm (ORCPT ); Wed, 27 Jul 2016 10:09:42 -0400 Date: Wed, 27 Jul 2016 16:09:38 +0200 From: Andrea Arcangeli To: "Kirill A. Shutemov" Cc: Jan Kara , "Theodore Ts'o" , "Kirill A. Shutemov" , Andreas Dilger , Jan Kara , Alexander Viro , Hugh Dickins , Andrew Morton , Dave Hansen , Vlastimil Babka , Matthew Wilcox , Ross Zwisler , linux-ext4@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, linux-block@vger.kernel.org Subject: Re: [PATCHv1, RFC 00/33] ext4: support of huge pages Message-ID: <20160727140938.lsvn6c7pwbodkeio@redhat.com> References: <1469493335-3622-1-git-send-email-kirill.shutemov@linux.intel.com> <20160726172938.GA9284@thunk.org> <20160726191212.GA11776@node.shutemov.name> <20160727091723.GG6860@quack2.suse.cz> <20160727103335.GE11776@node.shutemov.name> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160727103335.GE11776@node.shutemov.name> User-Agent: Mutt/1.6.2 (2016-06-11) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.27]); Wed, 27 Jul 2016 14:09:41 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hello, On Wed, Jul 27, 2016 at 01:33:35PM +0300, Kirill A. Shutemov wrote: > I guess you can get work 64k blocks with 4k pages if you *always* allocate > order-4 pages for page cache of the filesystem. But I don't think it's > sustainable. It's significant pressure on buddy allocator and compaction. Agreed. To guarantee compaction to succeed for a certain percentage of the RAM kernelcore= would need to be used, but the bigger the movable zone is, the bigger the imbalance will be, because the memory used by the kernel cannot use the RAM that is in the movable zone. If the movable zone is too big, early OOM failures may materialize where the kernel hits OOM despite there's plenty of free memory in the movable zone. So it's not ideal. > I guess the right approach would a mechanism to scatter one block to > multiple order-0 pages. At least for fallback. That would be ideal to avoid having to mess with kernelcore=, because no matter what direct compaction does (and current direction compaction defaults wouldn't be aggressive enough anyway), without kernelcore= the THP (or order4) allocation can fail at times. THP always requires a fallback so that a compaction failure isn't fatal and it can actually be fixed up later by khugepaged as more free memory becomes available at runtime. Thanks, Andrea