lkml.org 
[lkml]   [2014]   [Oct]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH v2] Security: smack: replace kzalloc with kmem_cache for inode_smack
    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@schaufler-ca.com>
    >>> To: Rohit <rohit.kr@samsung.com>
    >>> Cc: akpm@linux-foundation.org; james.l.morris@oracle.com; serge@hallyn.com; linux-security-module@vger.kernel.org; linux-kernel@vger.kernel.org; cpgs@samsung.com; pintu.k@samsung.com; vishnu.ps@samsung.com; iqbal.ams@samsung.com; ed.savinay@samsung.com; me.rohit@live.com; pintu_agarwal@yahoo.com; Casey Schaufler <casey@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 <casey@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.

    > ...



    \
     
     \ /
      Last update: 2014-10-27 02:21    [W:3.480 / U:0.164 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site