Re: [PATCH 1/1] stp: rt: replace spin_lock with stp style lock and use STP_ALLOC_FLAGS

[yzhu1 <Yanjun.Zhu@windriver.com>]

On 11/19/2015 01:14 AM, David Smith wrote:
> On 11/18/2015 02:14 AM, yzhu1 wrote:
>> Hi, David
>>
>> Thanks for your comments.
>>
>> I can not reproduce this problem. And my user can reproduce this problem
>> ocassionly.
>> And I requested him to help me to make tests about your changes. But he
>> refused.
>>
>> So I made auto tests in systemtap after this patch is applied. And I can
>> not find any
>> regressions about this patch.
Hi, David

Thanks for your comments.

Zhu Yanjun
> Most of the time you won't see any difference when using STP_ALLOC_FLAGS
> in place of STP_ALLOC_SLEEP_FLAGS. You would see a difference if your
> system is under memory pressure.
>
> Let me refresh everyone's knowledge of the difference between
> STP_ALLOC_FLAGS and STP_ALLOC_SLEEP_FLAGS. When using STP_ALLOC_FLAGS,
> if memory isn't available, the allocation will fail. When using
> STP_ALLOC_SLEEP_FLAGS, the kernel will try to wait until memory is
> available. Obviously, we can only use STP_ALLOC_SLEEP_FLAGS in certain
> places in the code where sleeping is permitted.
>
> If changing STP_ALLOC_SLEEP_FLAGS to STP_ALLOC_FLAGS makes a difference,
> this really means that we're using STP_ALLOC_SLEEP_FLAGS in a place
> where it isn't safe to sleep.
>
> It could be that in the normal kernel it is safe to sleep in a spot
> where we're using STP_ALLOC_SLEEP_FLAGS, but in the realtime kernel it
> isn't safe to sleep at that same spot. I guess it also makes sense to
> sleep as little as possible when running systemtap on the realtime kernel.
>
> So, I'll withdraw my objection. As long as the switch from
> STP_ALLOC_SLEEP_FLAGS to STP_ALLOC_FLAGS only affects the realtime
> kernel, I'm OK with it.
>