Message-id: <20141027122413.7edd8ee1@rohitk-ubuntu.sisodomain.com>
Date:	Mon, 27 Oct 2014 12:24:13 +0530
From:	Rohit <rohit.kr@...sung.com>
To:	Casey Schaufler <casey@...aufler-ca.com>
Cc:	PINTU KUMAR <pintu_agarwal@...oo.com>,
	"akpm@...ux-foundation.org" <akpm@...ux-foundation.org>,
	"james.l.morris@...cle.com" <james.l.morris@...cle.com>,
	"serge@...lyn.com" <serge@...lyn.com>,
	"linux-security-module@...r.kernel.org" 
	<linux-security-module@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"cpgs@...sung.com" <cpgs@...sung.com>,
	"pintu.k@...sung.com" <pintu.k@...sung.com>,
	"vishnu.ps@...sung.com" <vishnu.ps@...sung.com>,
	"iqbal.ams@...sung.com" <iqbal.ams@...sung.com>,
	"ed.savinay@...sung.com" <ed.savinay@...sung.com>,
	"me.rohit@...e.com" <me.rohit@...e.com>
Subject: Re: [PATCH v2] Security: smack: replace kzalloc with kmem_cache for
 inode_smack

On Sun, 26 Oct 2014 17:41:37 -0700
Casey Schaufler <casey@...aufler-ca.com> wrote:

> On 10/17/2014 10:37 AM, Casey Schaufler wrote:
> > On 10/17/2014 9:34 AM, PINTU KUMAR wrote:
> >> Hi,
> >>
> >>
> >>> ________________________________
> >>> From: Casey Schaufler <casey@...aufler-ca.com>
> >>> To: Rohit <rohit.kr@...sung.com> 
> >>> Cc: akpm@...ux-foundation.org; james.l.morris@...cle.com;
> >>> serge@...lyn.com; linux-security-module@...r.kernel.org;
> >>> linux-kernel@...r.kernel.org; cpgs@...sung.com;
> >>> pintu.k@...sung.com; vishnu.ps@...sung.com;
> >>> iqbal.ams@...sung.com; ed.savinay@...sung.com; me.rohit@...e.com;
> >>> pintu_agarwal@...oo.com; Casey Schaufler <casey@...aufler-ca.com>
> >>> Sent: Friday, 17 October 2014 8:08 PM Subject: Re: [PATCH v2]
> >>> Security: smack: replace kzalloc with kmem_cache for inode_smack
> >>>
> >>>
> >>> On 10/17/2014 4:42 AM, Rohit wrote:
> >>>> On Thu, 16 Oct 2014 09:24:01 -0700
> >>>> Casey Schaufler <casey@...aufler-ca.com> wrote:
> >>>>
> >>>>> On 10/15/2014 5:10 AM, Rohit wrote:
> >>>>>> The patch use kmem_cache to allocate/free inode_smack since
> >>>>>> they are alloced in high volumes making it a perfect case for
> >>>>>> kmem_cache.
> >>>>>>
> >>>>>> As per analysis, 24 bytes of memory is wasted per allocation
> >>>>>> due to internal fragmentation. With kmem_cache, this can be
> >>>>>> avoided.
> >>>>> What impact does this have on performance? I am much more
> >>>>> concerned with speed than with small amount of memory.
> >>>>>
> >>>> I think there should not be any performance problem as such.
> >>>> However, please let me know how to check the performance in this
> >>>> case.
> >>> Any inode intensive benchmark would suffice. Even the classic
> >>> kernel build would do.
> >>>
> >>>> As far as i know, kzalloc first finds the kmalloc_index
> >>>> corresponding to the size to get the kmem_cache_object and then
> >>>> calls kmem_cache_alloc with the kmalloc_index(kmem_cache
> >>>> object). Here, we create kmem_cache object specific for
> >>>> inode_smack and directly calls kmem_cache_alloc() which should
> >>>> give better performance as compared to kzalloc.
> >>> That would be my guess as well, but performance is tricky.
> >>> Sometimes things that "obviously" make performance better make it
> >>> worse. There can be unanticipated side effects.
> >>>
> >>>
> >>>> Please let me know your comments.
> >>> If you can run any sort of test that demonstrates this change
> >>> does not have performance impact, I'm fine with it. Smack is being
> >>> used in small devices, and both memory use and performance are
> >>> critical to the success of these devices. Of the two, performance
> >>> is currently more of an issue.
> >>>
> >> SMACK is used heavily in Tizen. We verified these changes for one
> >> of Tizen project. During boot time we observed that this object is
> >> used heavily, as identified by kmalloc-accounting. After replacing
> >> this we did not observe any difference in boot time. Also there
> >> was no side-effects seen so far. If you know of any other tests,
> >> please let us know. We will also try to gather some performance
> >> stats and present here.
> > We need to be somewhat more precise than "did not observe any
> > difference in boot time". The ideal benchmark would perform lots
> > of changes to the filesystem without doing lots of IO. One process
> > that matches that profile fairly well is a kernel make. I would be
> > satisfied with something as crude as using time(1) on a small (5?)
> > number of clean kernel makes each with and without the patch on the
> > running kernel. At the level of accuracy you usually get from
> > time(1) you won't find trivial differences, but if the change is a
> > big problem (or a big win) we'll know.
> 
> I have not seen anything indicating that the requested performance
> measurements have been done. I have no intention of accepting this
> without assurance that performance has not been damaged. I request
> that no one else carry this forward, either. The performance impact
> of security facilities comes under too much scrutiny to ignore it.
> 
> > ... 
> 
Sorry for the delay as I was on holiday for last week.
Will verify the performance impact as per your suggestion.
We verified it only on Tizen based ARM board, so building kernel on it
is not possible.
I found http://elinux.org/images/0/06/Buzov-SMACK.pdf (slides - 35-37)
for performance verification of smack. It checks performance of file
creation and copy in tmpfs. 
Please let me know whether the procedure mentioned in the above
mentioned slide is fine, else please suggest some other way to check
performance on the target board.


Regards,
Rohit

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists