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

[David Smith]

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.

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.

-- 
David Smith
dsmith@redhat.com
Red Hat
http://www.redhat.com
256.217.0141 (direct)
256.837.0057 (fax)