Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752049AbbGWF7b (ORCPT ); Thu, 23 Jul 2015 01:59:31 -0400 Received: from lgeamrelo04.lge.com ([156.147.1.127]:54315 "EHLO lgeamrelo04.lge.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750702AbbGWF7X (ORCPT ); Thu, 23 Jul 2015 01:59:23 -0400 X-Original-SENDERIP: 10.177.222.220 X-Original-MAILFROM: iamjoonsoo.kim@lge.com Date: Thu, 23 Jul 2015 15:03:48 +0900 From: Joonsoo Kim To: David Rientjes Cc: Vlastimil Babka , linux-mm@kvack.org, linux-kernel@vger.kernel.org, Andrew Morton , Hugh Dickins , Andrea Arcangeli , "Kirill A. Shutemov" , Rik van Riel , Mel Gorman Subject: Re: [RFC 1/4] mm, compaction: introduce kcompactd Message-ID: <20150723060348.GF4449@js1304-P5Q-DELUXE> References: <1435826795-13777-1-git-send-email-vbabka@suse.cz> <1435826795-13777-2-git-send-email-vbabka@suse.cz> 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: 1358 Lines: 27 Hello, On Thu, Jul 09, 2015 at 02:53:27PM -0700, David Rientjes wrote: > The slub allocator does try to allocate its high-order memory with > __GFP_WAIT before falling back to lower orders if possible. I would think > that this would be the greatest sign of on-demand memory compaction being > a problem, especially since CONFIG_SLUB is the default, but I haven't seen > such reports. In fact, some of our product had trouble with slub's high order allocation 5 months ago. At that time, compaction didn't make high order page and compaction attempts are frequently deferred. It also causes many reclaim to make high order page so I suggested masking out __GFP_WAIT and adding __GFP_NO_KSWAPD when trying slub's high order allocation to reduce reclaim/compaction overhead. Although using high order page in slub has some gains that reducing internal fragmentation and reducing management overhead, benefit is marginal compared to the cost at making high order page. This solution improves system response time for our case. I planned to submit the patch but it is delayed due to my laziness. :) Thanks. -- 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/