0.30.3 #126
0.30.3 #126
Conversation
donald
commented
Mar 20, 2022
•
donald
commented
- Avoid unbound job waiting time in certain conditions (job wait time unbound in certain conditions #125)
- Improve memory display in web pages
The truncation of '1500 GB' to (integer) '1 TB' is missleading. Make sure, we show a decimal place. Also use binary prefixes (e.g. KiB instead of kB) and correct the computation to binary prefixes where it is wrong.
Factor out reusable code into a new function could_potentially_start_job_for_user.
Factor out reusable code into new function can_start_job.
If a user is waiting for free resources, don't start jobs for later users, even if the later user doesn't have his so-called "fair share" of the cluster. Keep the (now unnecessary) "waiting"-flag, because we are adding another clause to the condition in the next commit.
Hoist up df_scratch one calllevel.
Only advertise WAITING state if there are jobs which could be started on this server.
_mx_sort_linked_list and its macro wrapper mx_sort_linked_list currently do a stable sort. Add comments to the code and the test that this is guaranteed behaviour, because we are going to depend on it in the following commits.
We are going to rely on the stability of the user list as a secondary preference criteria to the number of jobs running in the cluster. Put new user at the end of the user list so they start behind other waiting users and will stay behing them if the main crtieria (running_global_slot_count) is equal (e.g. zero).
Move a user, for whom a job was started, to the end of the user list. This way the server will do round-robin between users who have otherwise equal precedence based on running_global_slot_count.
Avoid sorting the user list when we are not going to start a job anyway. Also save a few source lines and remove a dead initalization.
gcc shows "warning: ‘status’ may be used uninitialized in this function [-Wmaybe-uninitialized]" on higher optimization levels. The variable will not be unitialized, if the code logic and the kernel process modell and system calls work as expected, but the compiler doesn't know about that. Initialize variable to a dont-care value to silence the compiler.
Add initalizations to avoid false warnings.
There was a problem hiding this comment.
On one hand (programmers view) it's nice tro have generic functions which scale up to YottaByte and use them almost anywhere.
But from user view I'd provide a function which makes "computer memory" readable. So cap the size at GB. so 1523 GB is more readble in a table with only GB columns than mixing 153 GB and 1.53 TB. I would even insert dots/commas at triplets which make it even more readble when right aligned.
|
Originally I've even had a comment |
|
Once you would like to show up disk space in mxq we're going towards Yotta 8-) |
We would have "MiB" anyway. And we don't want to express everything in "MiB", that would be difficult to read and make the rows to wide. (1TiB = 1048576 MiB). The cgi script is already installed for preview on afk. See http://afk.molgen.mpg.de/mxq/mxq/groups. We have groups with requested memory in TB, GB and MB.
I hate that. |
Sorry if I wasn't clear enough: I meant 'are you showing computer memory ? yes: show it in GB. In int(). maybe rounded." these columns will just look like Just Memory. But this can also apply to the req.tmpdir column. Where's the need for knowing '3 point zero GiB'. Memory is almost everywhere in GB nowadays. and if someone wants more.. well... I don't care if it's GB or GiB, it's the number of digits that make the columns hard to read. I'm driven by "let me have a quick look and parse the information that's given in the table". And if I see 3 digit numbers, they group together. I like the ' \d\d' (days|hrs|min) nevertheless, but that's because there are never more than 2 digits ( with exceptions ) and you walk down the strings to group.
your code, your rules. 8-) These are just suggestions to improve readability. Noone want to parse the output with a script. Screen -> Eyes -> Brain. |
