From 49a086299e047b18280457b654790ef4a2e5abfa Mon Sep 17 00:00:00 2001 From: Samuel Thibault Date: Wed, 18 Feb 2015 00:58:35 +0100 Subject: Revert "rename open_issues.mdwn to service_solahart_jakarta_selatan__082122541663.mdwn" This reverts commit 95878586ec7611791f4001a4ee17abf943fae3c1. --- open_issues/nice_vs_mach_thread_priorities.mdwn | 429 ++++++++++++++++++++++++ 1 file changed, 429 insertions(+) create mode 100644 open_issues/nice_vs_mach_thread_priorities.mdwn (limited to 'open_issues/nice_vs_mach_thread_priorities.mdwn') diff --git a/open_issues/nice_vs_mach_thread_priorities.mdwn b/open_issues/nice_vs_mach_thread_priorities.mdwn new file mode 100644 index 00000000..1f4c6ab8 --- /dev/null +++ b/open_issues/nice_vs_mach_thread_priorities.mdwn @@ -0,0 +1,429 @@ +[[!meta copyright="Copyright © 2010, 2012, 2013 Free Software Foundation, +Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!tag open_issue_gnumach open_issue_glibc]] + +This issue has been known for some time, due to coreutils' testsuite choking +when testing *nice*: [[!debbug 190581]]. + +There has been older discussion about this, too, but this is not yet captured +here. + + +# IRC, freenode, #hurd, 2010-08 + + I'm reading Mach and POSIX documentation to understand the priorities/nice problems + antrik said it would be better to reimplement everything instead of + fixing the current Mach interfaces, though I'm not sure about that yet + uh, so he changed his mind? + it seems POSIX doesn't say nice values should be -20..20, but + 0..(2*NZERO - 1) + he said we could just change the max priority value and be done + with it :) + so we can probably define NZERO to 16 to match the Mach range of + 0..31 + s/said/had said previously/ + youpi: POSIX is actually fucked up regarding the definition of + nice values + or at least the version I checked was + antrik: why? this says the range is [0,{NZERO}*2-1], so we can just + set NZERO to 16 AFAICS: + http://www.opengroup.org/onlinepubs/9699919799/functions/getpriority.html + it talkes about NZERO and all; making it *look* like this could be + defined arbitrarily... but in other places, it's clear that the standard + 40 level range is always assumed + anyways, I totally see no point in deviating from other systems in + this regard. it can only cause problems, and gives us no benefits + it says NZERO should be at least 20 iirc + agreed + I don't remember the details; it's been a while since I looked at + this + youpi: changing the number of levels is only part of the + issue. I'm not sure why I didn't mention it initially when we discussed + this + youpi: I already concluded years ago that it's not possible to + implement nice levels correctly with the current Mach interfaces in a + sane fashion + (it's probably possible, but only with a stupid hack like setting + all the thread priorities one by one) + youpi: also, last time we discussed this, I checked how the nice + stuff works currently on Hurd; and concluded that it's so utterly broken, + that there is no point in trying to preserve *any* compatibility. I think + we can safely throw away any handling that is alread there, and do it + over from scratch in the most straightforward fashion + antrik: I've thought about setting NZERO to 16 and doing exactly + what you've just said to be a hack (setting all the thread priorities one + by one) + but there seems to be consensus that that's undesirable... + indeed, POSIX says NZERO should be at least 20 + pochu: BTW, I forgot to say: I'm not sure you appreciate the + complexity of setting the thread max priorities individually + antrik: I don't. would it be too complex? I imagined it would be a + simple loop :) + pochu: in order to prevent race conditions, you have to stop all + other threads before obtaining the list of threads, and continue them + after setting the priority for each + I don't even know whether it can be done without interfering with + other thread handling... in which case it gets really really ugly + antrik: btw I'm looking at [gnumach]/kern/thread.[ch], removing the + priority stuff as appropriate, and will change the tasks code later + it seems to me that using a more suitable kernel interface will + not only be more elegant, but quite possibly actually easier to + implement... + antrik: apparently it's not that hard to change the priority for + all threads in a task, see task_priority() in gnumach/kern/task.c + it looks like the nice test failures are mostly because of the not + 1:1 mapping between nice values and Mach priorities + "Set priority of task; used only for newly created threads." + there is a reason I didn't fix nice 8 years ago + ah there is a change_threads option + marcusb: I'm not sure that comment is correct. that syscall is used + by setpriority() + yeah + I didn't read further, where it explains the change_threads + options + I was shooting before asking questions :) + pochu: although there are some bad interactions if max_priorities + are set per thread + pochu: maybe we are talking past each other. my point was not that + it's hard to do in the kernel. I was just saying that it would be painful + to do from userspace with the current kernel interface + antrik: you could still use that interface in user space, couldn't + you? or maybe I'm misunderstanding... + cfhammar, antrik: current patch: + http://emilio.pozuelo.org/~deb/gnumach.patch, main issue is probably what + to do with high-priority threads. are there cases where there should be a + thread with a high priority but the task's priority shouldn't be high? + e.g. what to do with kernel_thread() in [gnumach]/kern/thread.c + i.e. if tasks have a max_priority, then threads shouldn't have a + higher priority, but then either we raise the task's max_priority if we + need a high-prio thread, or we treat them specially (e.g. new field in + struct thread), or maybe it's a non-issue because in such cases, all the + task is high-prio? + also I wonder whether I can kill the processor set's + max_priority. It seems totally unused (I've checked gnumach, hurd and + glibc) + (that would simplify the priority handling) + pochu: btw what does your patch do? i can't remember what was + decided + cfhammar: it moves the max_priority from the thread to the task, so + raising/lowering it has effect on all of its threads + it also increases the number of run queues (and thus that of + priority levels) from 32 to 40 so we can have a 1:1 mapping with nice + values + cfhammar: btw don't do a full review yet, just a quick look would + be fine for now + why not do priorities from 0 to 159 + then both ranges can be scaled + without loss of precision + neal: there would be from Mach to nice priorities, e.g. a task with + a priority of 2 another with 3 would have the same niceness, though their + priority isn't really the same + pochu: sure + pochu: but any posix priority would map to a current mach priority + and back + sorry, that's not true + a posix priority would map to a new mach priority and bach + and a current mach priority would map to a new mach priority and + back + which is I think more desirable than changing to 40 priority levels + neal> and a current mach priority would map to a new mach priority + and back <- why should we care about this? + to be compatible with existing mach code + why gratutiously break existing interfaces? + they would break anyway, wouldn't them? i.e. if you do + task_set_priority(..., 20), you can't know if the caller is assuming old + or new priorities (to leave it as 20 or as 100) + you add a new interface + you should avoid changing the semantics of existing interfaces as + much as possible + ok, and deprecate the old ones I guess + following that rule, priorities only break if someone does + task_set_priority_new(..., X) and task_get_priority () + there are other users of Mach + I'd add a configure check for the new interface + alternatively, you can check at run time + well if you _set_priority_new(), you should _get_priority_new() :) + it's not always possible + other users of GNU Mach? + you are assuming you have complete control of all the code + this is usually not the case + no, other users of Mach + even apple didn't gratuitously break Mach + in fact, it may make sense to see how apple handles this problem + hmm, I hadn't thought about that + the other thing I don't understand is: "I'd add a configure check + for the new interface". a configure check where? in Mach's configure? + that doesn't make sense to me + any users of the interface + ok so in clients, e.g. glibc & hurd + yes. + neal: I'm not sure we are winning anything by keeping + compatibility with other users of Mach... + neal: we *know* that to make Hurd work really well, we have to do + major changes sooner or later. we can just as well start now IMHO + keeping compatibility just seems like extra effort without any + benefit for us + just OOC have all other Mach forks, preserved full compatibility? + guillem: Darwin is pretty compatible, as I understand it + pochu: the fundamental approach of changing the task_priority + interface to serve as a max priority, and to drop the notion of max + priorities from threads, looks fine + pochu: I'm not sure about the thread priority handling + I don't know how thread priorities are supposed to work in chreads + and/or pthread + I can only *guess* that they assume a two-stage scheduling + process, where the kernel first decides what process to run; and only + later which thread in a process... + if that's indeed the case, I don't think it's even possible to + implement with the current Mach scheduler + I guess we could work with relative thread priorities if we really + want: always have the highest-priority thread run with the task's max + priority, and lower the priorities of the other threads accordingly + however, before engaging into this, I think you should better + check whether any of the code in Hurd or glibc actually uses thread + priorities at all. my guess is that it doesn't + I think we could get away with stubbing out thread priority + handling alltogether for now, and just use the task priority for all + threads + I agree BTW that it would be useful to check how Darwin handles + this + btw do you know where to download the OS X kernel source? I found + something called xnu, but I?m not sure that's it + pochu: yeah, that's it + Darwin is the UNIX core of OS X, and Xnu is the actual kernel... + hmm, so they have both a task.priority and a task.max_priority + pochu: thoughts? + neal: they have a priority and a max_priority in the task and in + the threads, new threads inherit it from its parent task + then they have a task_priority(task, priority, max_priority) that + can change a task's priorities, and it also changes it for all its + threads + how does the global run queue work? + and they have 128 run queues, no idea if there's a special reason + for that number + neal: sorry, what do you mean? + I don't understand the point of the max_priority parameter + neal: and I don't understand the point of the (base) priority ;) + the max_priority is just that, the maximum priority of a thread, + which can be lowered, but can't exceed the max one + the (base) priority, I don't understand what it does, though I + haven't looked too hard. maybe it's the one a thread starts at, and must + be <= max_priority + pochu: it's clearly documented in the manual, as well as in the + code your initial patch changes... + or do you mean the meaning is different in Darwin?... + I was speaking of Darwin, though maybe it's the same as you say + I would assume it's the same. I don't think there would be any + point in having the base vs. max priority distinction at all, except to + stay in line with standard Mach... + at least I can't see a point in the base priority semantics for + use in POSIX systems... + right, it would make sense to always have priority == max_priority + ... + neal: so max_priority is that maximum priority, and priority is the + one used to calculate the scheduled priority, and can be raised and + lowered by the user without giving special permissions as long as he + doesn't raise it above max_priority + well this would allow a user to lower a process' priority, and + raise it again later, though that may not be allowed by POSIX, so then we + would want to have max_priority == priority (or get rid of one of them if + possible and backwards compatible) + pochu: right, that's what I think too + BTW, did I bring up handling of thread priorities? I know that I + meant to, but I don't remember whether I actually did... + antrik: you told me it'd be ok to just get rid of them for now + so I'm more thinking of fixing max_priority and (base) priority and + leaving thread's scheduling priority as it currently is + s/so/though/ + pochu: well, my fear is that keeping the thread priority handling + as ist while changing task priority handling would complicate the + changes, while giving us no real benefit... + though looking at what Darwin did there should give you an idea + what it involves exactly... + antrik: what would you propose, keeping sched_priority == + max_priority ? + s/keeping/making/ + yes, if that means what I think it does ;-) + and keeping the priority of all threads equal to the task priority + for now + of course this only makes sense if changing it like this is + actually simpler than extending the current handling... + again, I can't judge this without actually knowing the code in + question. looking at Darwin should give you an idea... + I think leaving it as is, making it work with the task's + max_priority changes would be easier + perhaps I'm totally overestimating the amount of changes required + to do what Darwin does + OTOH, carrying around dead code isn't exactly helping the + maintainability and efficiency of gnumach... + so I'm a bit ambivalent on this + should we go for minimal changes here, or use this occasion to + simplify things?... + I guess it would be good to bring this up on the ML + in the context of gsoc i'd say minimal changes + there's also neal's point on keeping backwards compatibility as + much as possible + my point was not backwards compatibility at all costs + I'm still not convinced this is a valid point :-) + but to not gratutiously break things + neal: well, I never suggested breaking things just because we + can... I only suggested breaking things to make the code and interface + simpler :-) + I do not insist on it though + at that time, we did not know how Mac did it + I only think it would be good to get into a habit that Mach + interfaces are not sacred... + and, I also had a proposal, which I think is not difficult to + implement given the existing patch + but as I said, I do not feel strongly about this. if people feel + more confident about a minimal change, I'm fine with that :-) + neal: err... IIRC your proposal was only about the number of nice + levels? we are discussing the interface change necessary to implement + POSIX semantics properly + or am I misremembering? + antrik: he argues that with that number of nice levels, we could + keep backwards compatibility for the 0..31 levels, and for 0..39 for + POSIX compatibility + pochu: yes, I remember that part + antrik : My suggestion was: raise the number of nice levels to 160 + and introduce a new interface which uses those. Adjust the old interface + to space by 160/32 + neal: I think I said it before: the problem is not *only* in the + number of priority levels. the semantics are also wrong. which is why + Darwin added a max_priority for tasks + what do you mean the semantics are wrong? + I apologize if you already explained this. + hm... I explained it at some point, but I guess you were not + present at that conversation + I got disconnected recently so I likely don't have it in backlog. + in POSIX, any process can lower its priority; while only + privileged processes can raise it + Mach distinguishes between "current" and "max" priority for + threads: "max" behaves like POSIX; while "current" can be raised or + lowered at will, as long as it stays below "max" + for tasks, there is only a "current" priority + (which applies to newly created threads, and optionally can be set + for all current threads while changing the task priority) + glibc currently uses the existing task priorities, which leads to + *completely* broken semantics + instead, we need something like a max task priority -- which is + exactly what Darwin added + yes + (the "current" task priority is useless for POSIX semantics as far + as I can tell; and regarding thread priorities, I doubt we actually use + them at all?...) + where does a new thread get its initial max_priority from? + cfhammar: from the creator thread IIRC + yes + + +## IRC, freenode, #hurd, 2010-08-12 + + my plan is to change the number of priority levels and the + threads/tasks priority handling, then add new RPCs to play with them and + make the old ones stay compatible, then make glibc use the new RPCs + + +# IRC, freenode, #hurd, 2012-12-29 + + and, for a reason that i can't understand, there are less + priorities than nice levels, despite the fact mach was designed to run + unix systems on top of it .. + btw, didn't we have a plan to increase that number? + i have no idea + but we should :) + I remember some discussion about it on the list + + +## IRC, freenode, #hurd, 2012-12-31 + + braunr: btw, we *do* have fixed the nice granularity + +#define MACH_PRIORITY_TO_NICE(prio) ((prio) - 20) + in the debian package at least + ah, no + it's not applied yet + so I have the patch under hand, just not applied :) + but that's a simple shift + the real problem is that there aren't as many mach priorities as + there are nice levels + that's not really a problem + we can raise that in the kernel + the problem is the change from shifted to unshifted + that brings odd nice values during the upgrade + ok + i hope the scheduler code isn't allergic to more priorities :) + + +## IRC, freenode, #hurd, 2013-01-02 + + pochu: i see you were working on nice levels and scheduling code + some time ago + pochu: anything new since then ? + braunr: nope + pochu: were you preparing it for the gsoc ? + braunr: can't remember right now, either that or to fix a ftbfs in + debian + iirc it's coreutils which wants proper nice levels + + +# IRC, OFTC, #debian-hurd, 2013-03-04 + + Is it not possible to set the priority of a process to 1 ? + these macros: + #define MACH_PRIORITY_TO_NICE(prio) (2 * ((prio) - 12)) + #define NICE_TO_MACH_PRIORITY(nice) (12 + ((nice) / 2)) + are used in the setpriority() implementation of Hurd + so setting a process' priority to 1 is just like setting it to 0 + Steap: that has already been discussed to drop the *2 + the issue is mach not supporting enough sched levels + can be fixed, of course + just nobody did yet + +GNU Mach commit 6a234201081156e6d5742e7eeabb68418b518fad (and commit +6fe36b76f7983ec9a2e8a70420e431d54252442e). + + +## IRC, OFTC, #debian-hurd, 2013-03-07 + + youpi: btw, why did you increase the number of priorites to 50 ? + for the nice levels + and probably something more, there are only 40 nice levels + yes, the current computation leaves some margin + so I preferred to keep a margin too + ok + e.g. for the idle thread, etc. + or interrupt threads + yep + i see the point, thanks + Is the number of 40 specified by POSIX (or whatever) or is that + a Linuxism? + good question + posix is weird when it comes to such old unixisms + there is a NZERO value, but i don't remember how it's specified + it's at least 20 + (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.) + "A maximum nice value of 2*{NZERO}-1 and a minimum nice value of 0 + shall be imposed by the system" + NZERO being 20 by default + and 20 is the minimum for NZERO too + hm, not the default, the minimul + minimum + yes that's it + ok so it's actually well specified + 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. + yep + thus failing in coreutils testsuite -- cgit v1.2.3