Message-id: <20141031093325.64808c2d@rohitk-ubuntu.sisodomain.com>
Date:	Fri, 31 Oct 2014 09:33:25 +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 Wed, 29 Oct 2014 08:12:05 -0700
Casey Schaufler <casey@...aufler-ca.com> wrote:

> On 10/29/2014 2:11 AM, Rohit wrote:
> > On Mon, 27 Oct 2014 09:25:28 -0700
> > Casey Schaufler <casey@...aufler-ca.com> wrote:
> >
> >> On 10/26/2014 11:54 PM, Rohit wrote:
> >>> 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.
> >> The technique outlined by Buzov should provide adequate evidence.
> > We carried out file creation of 0, 1k and 4k size for 1024 files
> > and measured the time taken. It was done for 5 iterations for each
> > case with kzalloc and kmem_cache on a board with 512MB RAM and 1.2
> > GHz dual core arm processor. The average latency is as follows :
> > File size   with kzalloc(in ms)   with kmem_cache(in ms)
> > %change 0           10925.6               10528.8
> > -3.63 1k           11909.8               11617.6
> > -2.45 4k           11632.2               11873.2
> > +2.07
> >
> > From the data, it seems that is no significant difference in
> > performance. Please let me know your opinion.
> 
> The data is kind of scary, don't you think? The performance
> starts out as an improvement, but gets worse as file size gets
> bigger. This could be anomalous with your choice of file size.
> We see that kzalloc performance improves going from 1k to 4k.
> 
> Can you run the same test with 10 (20 would be better) iterations
> for 0, 1k, 3k, 4k, 5k, 20k, 100k and 1m?
> 
> I am curious now. I will run my own tests as well.
>

Yes, i too found it odd for 4k file taking less time than 1k size.
Actually, issue was probably because I was using different block size
for file creation in two cases.

The latency for creating 1024 files with average of  10 iterations for
below file size is as follows:
File size   With Kzalloc(in ms)  With kmem_cache(in ms)     %change
0               10610.6              10595.4                 -0.14 
1k              11832.3              11667.4                 -1.39 
4k              11861.2              11802.1                 -0.49 
20k             11991.7              11977.7                 -0.11 
50k             12242.9              12224.7                 -0.14 
100k            12638.9              12581                   -0.45

It seems kmem_cache has little better performance compared to kzalloc.
Please share your comments and your test results,if any.


 

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