lkml.org 
[lkml]   [2008]   [Sep]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    SubjectRe: [PATCH 1/2] utrace core
    Date
    > Again, embed struct utrace directly into task_struct. task_struct
    > lifetime rules are way more tested than struct utrace ones.

    The most consistent feedback I've seen to all new features is that they
    mustn't add overhead when they're not being used. So I never considered it
    an option to bloat task_struct by ~120 bytes. Of course much more than
    that is entailed when a task is actually being traced somehow. But the
    presumption is that most tasks most of the time aren't, and that's what not
    to bloat.

    The revamp of the API after the first prototype made some of the internals
    much simpler to implement, that had been very sticky in the old prototype
    code. But the allocation and freeing of struct utrace is an area I did not
    fully revisit. Buggy is buggy, and sure it needs to be tested and fixed.
    I'm still inclined to look into making it right rather than punting.

    > Add simple spinlock guarding all accesses (OK, I haven't looked very
    > closely if it's possible)

    I can't tell what you mean here. Do you mean something different
    from struct utrace.lock? If there were no pointer and its allocation
    to synchronize, then what other lock would you be adding?

    > INIT_RCU_HEAD is not needed, call_rcu() will overwrite rcu head unconditionally.

    I see. Thanks! At some point, this was in the recommended example uses of
    RCU. This macro is still used in several places around the kernel.
    Shouldn't they all be removed? I wonder why it still exists in rcupdate.h.


    Thanks,
    Roland


    \
     
     \ /
      Last update: 2008-09-03 14:15    [W:5.035 / U:1.012 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site