Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932765AbcC3IXl (ORCPT ); Wed, 30 Mar 2016 04:23:41 -0400 Received: from LGEAMRELO11.lge.com ([156.147.23.51]:43911 "EHLO lgeamrelo11.lge.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932551AbcC3IXS (ORCPT ); Wed, 30 Mar 2016 04:23:18 -0400 X-Original-SENDERIP: 156.147.1.126 X-Original-MAILFROM: iamjoonsoo.kim@lge.com X-Original-SENDERIP: 10.177.222.138 X-Original-MAILFROM: iamjoonsoo.kim@lge.com Date: Wed, 30 Mar 2016 17:25:14 +0900 From: Joonsoo Kim To: Christoph Lameter Cc: Andrew Morton , Pekka Enberg , David Rientjes , Jesper Dangaard Brouer , linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH 06/11] mm/slab: don't keep free slabs if free_objects exceeds free_limit Message-ID: <20160330082514.GE1678@js1304-P5Q-DELUXE> References: <1459142821-20303-1-git-send-email-iamjoonsoo.kim@lge.com> <1459142821-20303-7-git-send-email-iamjoonsoo.kim@lge.com> 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: 1420 Lines: 40 On Mon, Mar 28, 2016 at 08:03:16PM -0500, Christoph Lameter wrote: > On Mon, 28 Mar 2016, js1304@gmail.com wrote: > > > From: Joonsoo Kim > > > > Currently, determination to free a slab is done whenever free object is > > put into the slab. This has a problem that free slabs are not freed > > even if we have free slabs and have more free_objects than free_limit > > There needs to be a better explanation here since I do not get why there > is an issue with checking after free if a slab is actually free. Okay. Consider following 3 objects free situation. free_limt = 10 nr_free = 9 free(free slab) free(free slab) free(not free slab) If we check it one by one, when nr_free > free_limit (at last free), we cannot free the slab because current slab isn't a free slab. But, if we check it lastly, we can free 1 free slab. I will add more explanation on the next version. > > > when processed slab isn't a free slab. This would cause to keep > > too much memory in the slab subsystem. This patch try to fix it > > by checking number of free object after all free work is done. If there > > is free slab at that time, we can free it so we keep free slab as minimal > > as possible. > > Ok if we check after free work is done then the number of free slabs may > be higher than the limit set and then we free the additional slabs to get > down to the limit that was set? Yes. Thanks.