From 99f17f532f1ed1322f93ea1dd495e7d332ec4926 Mon Sep 17 00:00:00 2001 From: "jbranso@dismail.de" Date: Sun, 14 Jan 2024 21:33:43 -0500 Subject: removed the the pages that mentioned "nice" issues. Both issues have been fixed. * open_issues/nice_changes_priority_of_parent_shell.mdwn: deleted * open_issues/nice_vs_mach_thread_priorities.mdwn: deleted * hurd/porting/system_api_limitations.mdwn: remove entry that said "nice () doesn't work". Message-ID: <20240115023446.6431-1-jbranso@dismail.de> --- hurd/porting/system_api_limitations.mdwn | 2 - .../nice_changes_priority_of_parent_shell.mdwn | 15 - open_issues/nice_vs_mach_thread_priorities.mdwn | 429 --------------------- 3 files changed, 446 deletions(-) delete mode 100644 open_issues/nice_changes_priority_of_parent_shell.mdwn delete mode 100644 open_issues/nice_vs_mach_thread_priorities.mdwn diff --git a/hurd/porting/system_api_limitations.mdwn b/hurd/porting/system_api_limitations.mdwn index 1615ccc0..3ab4e406 100644 --- a/hurd/porting/system_api_limitations.mdwn +++ b/hurd/porting/system_api_limitations.mdwn @@ -22,8 +22,6 @@ These are the known system API limits that have porting implications. **_[\#47998](http://bugs.debian.org/47998): `msgget` IPC not implemented_** -**_[[nice() doesn't work|open_issues/nice_vs_mach_thread_priorities]]_**. - **_[\#187391](http://bugs.debian.org/187391): libc0.3-dev: `sockaddr_un.sun_path` can't be assigned a `const char *` when compiling with g++_**
**breaks:** fam, gail
**status:** maybe this should be in [[PortingIssues]] (see _long_ bug log) **_[\#190367](http://bugs.debian.org/190367): libc0.3-dev: `fcntl` `F_GETLK` not implemented (`ENOSYS`)_**
**breaks:** gnome-session (and others) from running
**error:** misc lock-related errors diff --git a/open_issues/nice_changes_priority_of_parent_shell.mdwn b/open_issues/nice_changes_priority_of_parent_shell.mdwn deleted file mode 100644 index a8a08f90..00000000 --- a/open_issues/nice_changes_priority_of_parent_shell.mdwn +++ /dev/null @@ -1,15 +0,0 @@ -[[!meta copyright="Copyright © 2010 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]] - - * [[!debbug 44039]] - - * Also see [[nice_vs_mach_thread_priorities]]. diff --git a/open_issues/nice_vs_mach_thread_priorities.mdwn b/open_issues/nice_vs_mach_thread_priorities.mdwn deleted file mode 100644 index 1f4c6ab8..00000000 --- a/open_issues/nice_vs_mach_thread_priorities.mdwn +++ /dev/null @@ -1,429 +0,0 @@ -[[!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