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 S1757550AbcH2OtT (ORCPT <rfc822;w@1wt.eu>);
        Mon, 29 Aug 2016 10:49:19 -0400
Received: from resqmta-po-04v.sys.comcast.net ([96.114.154.163]:42537 "EHLO
        resqmta-po-04v.sys.comcast.net" rhost-flags-OK-OK-OK-OK)
        by vger.kernel.org with ESMTP id S1757427AbcH2OtS (ORCPT
        <rfc822;linux-kernel@vger.kernel.org>);
        Mon, 29 Aug 2016 10:49:18 -0400
Date: Mon, 29 Aug 2016 09:49:09 -0500 (CDT)
From: Christoph Lameter <cl@linux.com>
X-X-Sender: cl@east.gentwo.org
To: Michal Hocko <mhocko@kernel.org>
cc: Andi Kleen <andi@firstfloor.org>, 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
In-Reply-To: <20160829134458.GD2968@dhcp22.suse.cz>
Message-ID: <alpine.DEB.2.20.1608290947140.21668@east.gentwo.org>
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> <20160829134458.GD2968@dhcp22.suse.cz>
Content-Type: text/plain; charset=US-ASCII
X-CMAE-Envelope: MS4wfEqnXGMOwtmMwTGDOwuC7x/bedGUH94O8P79PbnqXbLCtD4LIomC2/MyJwePbobwK634m6pKsG58+Gd8dVouA3i5Lc7PuJu4Y4dPBi4ThPmN/7bFOBn7
 hrKyp8pnq1hcUlluogJI44W+C1oHOpy1J62SVN29Otw9Lfnr4Ky9wZqinhKQd7ZnWpq+7GYB6k6FRTuGPDohF+Bv/irHyuefpVeBu9H4OQ8rg0qeJYV6c6AM
 jDhqLAvDoJv088hGrRfZvMEe+12J9zDIgSRbgV4hy1m0FjVLwiwwzCKCUPsqKeoyHLxLozGwimKoM0l/bZVEVR+L4emWN9H86ZlM1uS/AqHXvXrN829mSWA8
 ROzF68cP4rS1VfOLm4QDjNCJm3m7z4HQ/g55Pbb6j2ZjU9mP6gZ36Q2Kk5Fcez//EnO+GvfSb2fgEnok/A1tD+6dE3TZzqFF0n/Hd59mZEK2PEittqu+EoAz
 Oo9pUnCaqnALlPs6Z01fxx4KpvHJgG/9OHSgePNTElHHB62hsjBFPg7wdtw=
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Mon, 29 Aug 2016, Michal Hocko wrote:

> 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.

Compaction needs to be able to move many more types of kernel objects out
of the way. I think if the callbacks that were merged for the migration of
CMA pages are made usable for slab allocations then we may make some
progress there. This would require the creator of a slab cache to specify
functions that allow the migration of an object. Would require additional
subsystem specific code. But doing that for inodes and dentries could be
very benficial for compaction.