Received: by 2002:a25:8b12:0:0:0:0:0 with SMTP id i18csp314516ybl; Thu, 29 Aug 2019 23:41:20 -0700 (PDT) X-Google-Smtp-Source: APXvYqzcmd+Yr+pHFRzNQEs7hWfzwqjfL1UFxSWnYIss9AgioHjZt50RAHKYj+zV+I217cMHd+TE X-Received: by 2002:a63:a302:: with SMTP id s2mr11810755pge.125.1567147279928; Thu, 29 Aug 2019 23:41:19 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1567147279; cv=none; d=google.com; s=arc-20160816; b=fq3N01KvxNoV1ywb/HmsxKRJzr9eTQFmfgYSFOIxIOnvixdQiAlI08TxWz8d9PDR/M n2ttcafFYeDbggdr3ZFoXgxjU18UvQXhZd6I4AHvxRk0Vl0vG7NLbV+sOlsVjicgq7ae zoVLvT4uAjb3zJ9H4uNzoPnPaQSc+Ku/IPsMBRTf0bQ8Gs0EHcOSa+Gj0ti/7b71OuCu Ir0axymPGhpV1N+aNVizt+TUllLe53MmMFNEjk6Bzpqzac5vNDlznCB7pPTCmgPyTqLd toV6AkpDA8YiLkwAtQYgMsm3+RksdcneRTwxuMZVhz2PFWQYlBE7YRUNlZKVm8+r934U zjMA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:dkim-signature; bh=HH8bNIdrnP4v98R8UlLby/7z0GeM4ZKLmFtGS9rz9Rk=; b=KKaXjuH2BNyglkSUmLIV7hj+y4HxL/uf1ZLY/69qR9Oe7W+e+tsz1i+Zct5bi98cfW ovRjqYRaXgZPi49ZLK4yPfZPAlhiFus38y2qlaCIT9tp09n2t/BXzXX4yiqweNmBYqWg 0mNoQtZtg0WPQCAtqoER3W0EO67jegiPTb3jbQ/QU7rUO/05hp+AnDba4X9DgczVlW4f r4FZjOBJMUgiGG6hfEuOhEk40n3tRi/s0dW827ChHZobFtJXQgWPZT+x7yplSc4gjS7I kYwh9RvMU7IqN3Lh1Y31tE3QMMtcvfPiExxtHjdKt0kDJVbwSUMzOUAB1k0KVtDF6W3+ SH7w== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=NLua+rWZ; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id w11si2426130pjq.42.2019.08.29.23.41.03; Thu, 29 Aug 2019 23:41:19 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=NLua+rWZ; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728076AbfH3Gjr (ORCPT + 99 others); Fri, 30 Aug 2019 02:39:47 -0400 Received: from mail.kernel.org ([198.145.29.99]:37652 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726005AbfH3Gjr (ORCPT ); Fri, 30 Aug 2019 02:39:47 -0400 Received: from localhost (83-86-89-107.cable.dynamic.v4.ziggo.nl [83.86.89.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id C431421726; Fri, 30 Aug 2019 06:39:45 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1567147186; bh=7/rlq7vaiQOs31GzJFIA6k/xmE5490eBtARLEuRFq7Y=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=NLua+rWZfK61axwTbxetb7LZfM7o5wumj8OLYbaDAq4Dbw4SnLP64ExzXhrtBV6PE R4xhiF3XthsZRRTmTKpxP7R+X6necCQY2PuG14kcWtklm4XHPs1zPu7SRbhEZmrmWy +wK//lHXUFRzZRT/AhPZ8J9iXo5HGB7ylBYjLv/4= Date: Fri, 30 Aug 2019 08:39:43 +0200 From: Greg KH To: Peikan Tsai Cc: Christian Brauner , devel@driverdev.osuosl.org, tkjos@android.com, linux-kernel@vger.kernel.org, arve@android.com, Joel Fernandes , maco@android.com Subject: Re: [PATCH] binder: Use kmem_cache for binder_thread Message-ID: <20190830063943.GH15257@kroah.com> References: <20190829054953.GA18328@mark-All-Series> <20190829064229.GA30423@kroah.com> <20190829135359.GB63638@google.com> <20190829152721.ttsyfwaeygmwmcu7@wittgenstein> <20190829185901.GA4680@mark-All-Series> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190829185901.GA4680@mark-All-Series> User-Agent: Mutt/1.12.1 (2019-06-15) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Aug 30, 2019 at 02:59:01AM +0800, Peikan Tsai wrote: > On Thu, Aug 29, 2019 at 05:27:22PM +0200, Christian Brauner wrote: > > On Thu, Aug 29, 2019 at 09:53:59AM -0400, Joel Fernandes wrote: > > > On Thu, Aug 29, 2019 at 08:42:29AM +0200, Greg KH wrote: > > > > On Thu, Aug 29, 2019 at 01:49:53PM +0800, Peikan Tsai wrote: > > > [snip] > > > > > The allocated size for each binder_thread is 512 bytes by kzalloc. > > > > > Because the size of binder_thread is fixed and it's only 304 bytes. > > > > > It will save 208 bytes per binder_thread when use create a kmem_cache > > > > > for the binder_thread. > > > > > > > > Are you _sure_ it really will save that much memory? You want to do > > > > allocations based on a nice alignment for lots of good reasons, > > > > especially for something that needs quick accesses. > > > > > > Alignment can be done for slab allocations, kmem_cache_create() takes an > > > align argument. I am not sure what the default alignment of objects is > > > though (probably no default alignment). What is an optimal alignment in your > > > view? > > > > Probably SLAB_HWCACHE_ALIGN would make most sense. > > > > Agree. Thanks for yours comments and suggestions. > I'll put SLAB_HWCACHE_ALIGN it in patch v2. > > > > > > > > Did you test your change on a system that relies on binder and find any > > > > speed improvement or decrease, and any actual memory savings? > > > > > > > > If so, can you post your results? > > > > > > That's certainly worth it and I thought of asking for the same, but spoke too > > > soon! > > > > Yeah, it'd be interesting to see what difference this actually makes. > > > > Christian > > I tested this change on an Android device(arm) with AOSP kernel 4.19 and > observed > memory usage of binder_thread. But I didn't do binder benchmark yet. > > On my platform the memory usage of binder_thread reduce about 90 KB as > the > following result. > nr obj obj size total > before: 624 512 319488 bytes > after: 728 312 227136 bytes You have more objects???