From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S933521AbcH2NpD (ORCPT <rfc822;w@1wt.eu>);
        Mon, 29 Aug 2016 09:45:03 -0400
Received: from mail-wm0-f51.google.com ([74.125.82.51]:38701 "EHLO
        mail-wm0-f51.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S932908AbcH2NpB (ORCPT
        <rfc822;linux-kernel@vger.kernel.org>);
        Mon, 29 Aug 2016 09:45:01 -0400
Date: Mon, 29 Aug 2016 15:44:58 +0200
From: Michal Hocko <mhocko@kernel.org>
To: Andi Kleen <andi@firstfloor.org>
Cc: Christoph Lameter <cl@linux.com>, Mel Gorman <mgorman@suse.de>,
        Joonsoo Kim <iamjoonsoo.kim@lge.com>,
        Aruna Ramakrishna <aruna.ramakrishna@oracle.com>, linux-mm@kvack.org,
        linux-kernel@vger.kernel.org, Mike Kravetz <mike.kravetz@oracle.com>,
        Pekka Enberg <penberg@kernel.org>,
        David Rientjes <rientjes@google.com>,
        Andrew Morton <akpm@linux-foundation.org>, Jiri Slaby <jslaby@suse.cz>
Subject: Re: what is the purpose of SLAB and SLUB
Message-ID: <20160829134458.GD2968@dhcp22.suse.cz>
References: <1471458050-29622-1-git-send-email-aruna.ramakrishna@oracle.com>
 <20160818115218.GJ30162@dhcp22.suse.cz>
 <20160823021303.GB17039@js1304-P5Q-DELUXE>
 <20160823153807.GN23577@dhcp22.suse.cz>
 <20160824082057.GT2693@suse.de>
 <alpine.DEB.2.20.1608242240460.1837@east.gentwo.org>
 <20160825100707.GU2693@suse.de>
 <alpine.DEB.2.20.1608251451070.10766@east.gentwo.org>
 <87h9a71clo.fsf@tassilo.jf.intel.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <87h9a71clo.fsf@tassilo.jf.intel.com>
User-Agent: Mutt/1.6.0 (2016-04-01)
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Fri 26-08-16 13:47:47, Andi Kleen wrote:
> Christoph Lameter <cl@linux.com> writes:
> >
> >> If you want to rework the VM to use a larger fundamental unit, track
> >> sub-units where required and deal with the internal fragmentation issues
> >> then by all means go ahead and deal with it.
> >
> > Hmmm... The time problem is always there. Tried various approaches over
> > the last decade. Could be a massive project. We really would need a
> > larger group of developers to effectively do this.
> 
> I'm surprised that compactions is not able to fix the fragmentation.
> Is the problem that there are too many non movable objects around?

Compaction can certainly help and the more we are proactive in that
direction the better. Vlastimil has already done a first step in that
direction and we a have a dedicated kcompactd kernel thread for that
purpose. But I guess what Mel had in mind is the latency of higher
order pages which is inherently higher with the current page allocator
no matter how well the compaction works. There are other changes, mostly
for the fast path, needed to make higher order pages less of a second
citizen.
-- 
Michal Hocko
SUSE Labs