From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753910AbcHSFsR (ORCPT ); Fri, 19 Aug 2016 01:48:17 -0400 Received: from aserp1040.oracle.com ([141.146.126.69]:28836 "EHLO aserp1040.oracle.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750879AbcHSFsQ (ORCPT ); Fri, 19 Aug 2016 01:48:16 -0400 Subject: Re: [PATCH v3] mm/slab: Improve performance of gathering slabinfo stats To: Michal Hocko References: <1471458050-29622-1-git-send-email-aruna.ramakrishna@oracle.com> <20160818115218.GJ30162@dhcp22.suse.cz> Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org, Mike Kravetz , Christoph Lameter , Pekka Enberg , David Rientjes , Joonsoo Kim , Andrew Morton From: aruna.ramakrishna@oracle.com Organization: Oracle Corporation Message-ID: <57B69D8F.5000101@oracle.com> Date: Thu, 18 Aug 2016 22:47:59 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.7.0 MIME-Version: 1.0 In-Reply-To: <20160818115218.GJ30162@dhcp22.suse.cz> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Source-IP: userv0021.oracle.com [156.151.31.71] Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 08/18/2016 04:52 AM, Michal Hocko wrote: > I am not opposing the patch (to be honest it is quite neat) but this > is buggering me for quite some time. Sorry for hijacking this email > thread but I couldn't resist. Why are we trying to optimize SLAB and > slowly converge it to SLUB feature-wise. I always thought that SLAB > should remain stable and time challenged solution which works reasonably > well for many/most workloads, while SLUB is an optimized implementation > which experiment with slightly different concepts that might boost the > performance considerably but might also surprise from time to time. If > this is not the case then why do we have both of them in the kernel. It > is a lot of code and some features need tweaking both while only one > gets testing coverage. So this is mainly a question for maintainers. Why > do we maintain both and what is the purpose of them. Michal, Speaking about this patch specifically - I'm not trying to optimize SLAB or make it more similar to SLUB. This patch is a bug fix for an issue where the slowness of 'cat /proc/slabinfo' caused timeouts in other drivers. While optimizing that flow, it became apparent (as Christoph pointed out) that one could converge this patch to SLUB's current implementation. Though I have not done that in this patch (because that warrants a separate patch), I think it makes sense to converge where appropriate, since they both do share some common data structures and code already. Thanks, Aruna From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oi0-f72.google.com (mail-oi0-f72.google.com [209.85.218.72]) by kanga.kvack.org (Postfix) with ESMTP id C64FF82F5F for ; Fri, 19 Aug 2016 01:48:11 -0400 (EDT) Received: by mail-oi0-f72.google.com with SMTP id 4so97005156oih.2 for ; Thu, 18 Aug 2016 22:48:11 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com. [141.146.126.69]) by mx.google.com with ESMTPS id z68si2818245itd.12.2016.08.18.22.48.11 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 18 Aug 2016 22:48:11 -0700 (PDT) Subject: Re: [PATCH v3] mm/slab: Improve performance of gathering slabinfo stats References: <1471458050-29622-1-git-send-email-aruna.ramakrishna@oracle.com> <20160818115218.GJ30162@dhcp22.suse.cz> From: aruna.ramakrishna@oracle.com Message-ID: <57B69D8F.5000101@oracle.com> Date: Thu, 18 Aug 2016 22:47:59 -0700 MIME-Version: 1.0 In-Reply-To: <20160818115218.GJ30162@dhcp22.suse.cz> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org List-ID: To: Michal Hocko Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org, Mike Kravetz , Christoph Lameter , Pekka Enberg , David Rientjes , Joonsoo Kim , Andrew Morton On 08/18/2016 04:52 AM, Michal Hocko wrote: > I am not opposing the patch (to be honest it is quite neat) but this > is buggering me for quite some time. Sorry for hijacking this email > thread but I couldn't resist. Why are we trying to optimize SLAB and > slowly converge it to SLUB feature-wise. I always thought that SLAB > should remain stable and time challenged solution which works reasonably > well for many/most workloads, while SLUB is an optimized implementation > which experiment with slightly different concepts that might boost the > performance considerably but might also surprise from time to time. If > this is not the case then why do we have both of them in the kernel. It > is a lot of code and some features need tweaking both while only one > gets testing coverage. So this is mainly a question for maintainers. Why > do we maintain both and what is the purpose of them. Michal, Speaking about this patch specifically - I'm not trying to optimize SLAB or make it more similar to SLUB. This patch is a bug fix for an issue where the slowness of 'cat /proc/slabinfo' caused timeouts in other drivers. While optimizing that flow, it became apparent (as Christoph pointed out) that one could converge this patch to SLUB's current implementation. Though I have not done that in this patch (because that warrants a separate patch), I think it makes sense to converge where appropriate, since they both do share some common data structures and code already. Thanks, Aruna -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org