Summary: | staprun should not self-renice | ||
---|---|---|---|
Product: | systemtap | Reporter: | Frank Ch. Eigler <fche> |
Component: | runtime | Assignee: | Unassigned <systemtap> |
Status: | RESOLVED FIXED | ||
Severity: | minor | ||
Priority: | P3 | ||
Version: | unspecified | ||
Target Milestone: | --- | ||
Host: | Target: | ||
Build: | Last reconfirmed: |
Description
Frank Ch. Eigler
2007-07-12 10:59:05 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. basic renicing code was done some time ago; commit 70514d6 finishes the job. |