Bug 70321
| Summary: | PRIO_MAX defined to wrong value | ||
|---|---|---|---|
| Product: | Process Management | Reporter: | Phillip Susi (phill) |
| Component: | Other | Assignee: | process_other |
| Status: | NEW --- | ||
| Severity: | normal | CC: | alan, lkml |
| Priority: | P1 | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Kernel Version: | All | Subsystem: | |
| Regression: | No | Bisected commit-id: | |
|
Description
Phillip Susi
2014-02-09 02:54:47 UTC
I don't believe this is a bug. " On some systems, the range of nice values is -20..20." according to the manual page and I think historically so. The kernel maps them onto a -20 to 19 range currently but the API was -20 to +20 Is there a case this shows up as non conforming ? It is non conforming because it states that the api accepts 20, but it in fact, does not. What exactly is "some systems"? I can only imagine that at some point in the distant past it did accept 20, and this was changed without updating the value of PRIO_MAX to match. As a result of this the man page for renice in util-linux currently says that you can set it to the value of PRIO_MAX ( 20 ), which is incorrect. I have submitted a patch to fix the man page, and a bug to glibc to fix the value of this #define in their headers, but they say they are just using the value from the kernel headers. If I set a value of 20 it is clipped to 19 rather than errored. That appears to be compliant with standards ? Sure; the system call is supposed to clip rather than error, but the symbol is supposed to define where that point is so that a program can determine it at compile time rather than through trial and error at runtime. I see -20 in use, does +20 get mapped to batch or idle?
A bunch at -20: w/wchan @~50/50 worker/rescue. rescue<-waiting for by :(kdmflush,dio/xfs-{data,conv,cil},bioset,kcopyd,ksnaphd)
|