diff options
| author | Thomas Schwinge <tschwinge@gnu.org> | 2013-04-07 18:18:44 +0200 |
|---|---|---|
| committer | Thomas Schwinge <tschwinge@gnu.org> | 2013-04-07 18:18:44 +0200 |
| commit | 6c7d45e4631784d0e077e806521a736da6b0266e (patch) | |
| tree | f9d3e9ed304e8cdbf72fc77c135781eb49990f6a /open_issues/nice_vs_mach_thread_priorities.mdwn | |
| parent | f8ed211a4da23edf469089254b3dace9479bf11f (diff) | |
| download | web-6c7d45e4631784d0e077e806521a736da6b0266e.tar.gz web-6c7d45e4631784d0e077e806521a736da6b0266e.tar.bz2 web-6c7d45e4631784d0e077e806521a736da6b0266e.zip | |
IRC.
Diffstat (limited to 'open_issues/nice_vs_mach_thread_priorities.mdwn')
| -rw-r--r-- | open_issues/nice_vs_mach_thread_priorities.mdwn | 40 |
1 files changed, 40 insertions, 0 deletions
diff --git a/open_issues/nice_vs_mach_thread_priorities.mdwn b/open_issues/nice_vs_mach_thread_priorities.mdwn index e27d3018..1f4c6ab8 100644 --- a/open_issues/nice_vs_mach_thread_priorities.mdwn +++ b/open_issues/nice_vs_mach_thread_priorities.mdwn @@ -387,3 +387,43 @@ here. <youpi> the issue is mach not supporting enough sched levels <youpi> can be fixed, of course <youpi> just nobody did yet + +GNU Mach commit 6a234201081156e6d5742e7eeabb68418b518fad (and commit +6fe36b76f7983ec9a2e8a70420e431d54252442e). + + +## IRC, OFTC, #debian-hurd, 2013-03-07 + + <braunr> youpi: btw, why did you increase the number of priorites to 50 ? + <youpi> for the nice levels + <braunr> and probably something more, there are only 40 nice levels + <youpi> yes, the current computation leaves some margin + <youpi> so I preferred to keep a margin too + <braunr> ok + <youpi> e.g. for the idle thread, etc. + <braunr> or interrupt threads + <youpi> yep + <braunr> i see the point, thanks + <tschwinge> Is the number of 40 specified by POSIX (or whatever) or is that + a Linuxism? + <braunr> good question + <braunr> posix is weird when it comes to such old unixisms + <braunr> there is a NZERO value, but i don't remember how it's specified + <youpi> it's at least 20 + <tschwinge> (I don't object to the change; just wondered. And if practice, + you probably wouldn't really need more than a handful. But if that + change (plus some follow-up in glibc (?) improves something while not + adding a lot of overhead, then that's entirely fine, of course.) + <braunr> "A maximum nice value of 2*{NZERO}-1 and a minimum nice value of 0 + shall be imposed by the system" + <braunr> NZERO being 20 by default + <youpi> and 20 is the minimum for NZERO too + <braunr> hm, not the default, the minimul + <braunr> minimum + <braunr> yes that's it + <braunr> ok so it's actually well specified + <tschwinge> Aha, I see (just read it, too). So before that change we + simply couldn't satisfy the POSIX requirement of (minimum) NZERO = 20, + and allowing for step-1 increments. Alright. + <youpi> yep + <youpi> thus failing in coreutils testsuite |