On 10/17/2014 10:37 AM, Casey Schaufler wrote: > On 10/17/2014 9:34 AM, PINTU KUMAR wrote: >> Hi, >> >> >>> ________________________________ >>> From: Casey Schaufler <ca...@schaufler-ca.com> >>> To: Rohit <rohit...@samsung.com> >>> Cc: a...@linux-foundation.org; james.l.mor...@oracle.com; se...@hallyn.com; >>> linux-security-mod...@vger.kernel.org; linux-kernel@vger.kernel.org; >>> c...@samsung.com; pint...@samsung.com; vishnu...@samsung.com; >>> iqbal....@samsung.com; ed.savi...@samsung.com; me.ro...@live.com; >>> pintu_agar...@yahoo.com; Casey Schaufler <ca...@schaufler-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 <ca...@schaufler-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. > ... -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
