Bug 4783 - staprun should not self-renice
Summary: staprun should not self-renice
Status: RESOLVED FIXED
Alias: None
Product: systemtap
Classification: Unclassified
Component: runtime (show other bugs)
Version: unspecified
: P3 minor
Target Milestone: ---
Assignee: Unassigned
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2007-07-12 10:59 UTC by Frank Ch. Eigler
Modified: 2008-11-28 15:57 UTC (History)
0 users

See Also:
Host:
Target:
Build:
Last reconfirmed:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Frank Ch. Eigler 2007-07-12 10:59:05 UTC 
Even if you can justify renicing for the transport phase (I'd like to see
numbers if you have any), staprun should renice itself back to zero for
anything non-time-critical.

See http://lkml.org/lkml/2007/7/11/316.  Yes, it's a kernel bug, but still
we should not get into this situation in the first place.
Comment 1 Martin Hunt 2007-08-15 14:50:56 UTC 
staprun now renices itself back to 0 before removing the module.

The reason for bumping the priority in the first place was problems encountered
when probes were trigger by high-priority processes. staprun couldn't get enough
time to empty the buffers so there were always lots of dropped packets. I'm sure
the situation has improved but haven't really tried to construct any new test
cases to see.  Logically you will always have this problem with a very high
priority process logging too much data.
Comment 2 Frank Ch. Eigler 2008-11-28 15:57:18 UTC 
basic renicing code was done some time ago; commit 70514d6 finishes the job.