Send it through the earth, you can reduce it theoretically to 42.5ms
This isn't as ridiculous as it sounds and you just need a neutrino-beam... which has a horrible bandwidth (of 0.1 bits/s) plus the ridiculous upfront cost of running two particle-accelerators for a full-duplex link. (Google it up, this exists.)
A kernel was released that changed how the hash value got computed for casefolded filenames. (used for better windows compatibility) That kernel then went into production. This unfortunately split some file-systems that supported this into two incompatible versions, breaking the kernel rule 1.
There might now exist file-systems were created/modified with this bug present that the old/fixed kernels can't understand.
I was reluctant to take this project, knowing well I would end up deleting nearly all existing code I would have to touch, all while having just mediocre skill writing its successor, if it ever becomes one.
I can no longer escape from this project, nor do have I will to.
Sugar is half bad, half good: the glucose part causes no harm and whole body can use it. The fructose part on otherhand is bad and has to/can only be processed by the liver first.
PS: I will never get away from the fact that user-space memory addresses are also basically keys into the page table, so it is hashtables all the way down - you cannot escape them.
This means that you reset your password with a 32-character long generated password, which is saved in your vault, PlayStation saves a 30-long password and then you use the 32-long password to log in, which fails because it isn’t the same.
"The kernel runs out of time to solve the NP-complete scheduling problem in time."
More responsiveness requires more context-switching, which then subtracts from the available total CPU bandwidth.
There is a point where the task scheduler and CPUs get so overloaded that a non-RT kernel can no longer guarantee timed events.
So, web browsing is basically poison for the task scheduler under high load. Unless you reserve some CPU bandwidth (with cgroups, etc.) beforehand for the foreground task.
Since SMT threads also aren't real cores (about ~0.4 - 0.7 of an actual core), putting 16 tasks on a 16/8 machine is only going to slow down the execution of all other tasks on the shared cores.
I usually leave one CPU thread for "housekeeping" if I need to do something else. If I don't, some random task is going to be very pleased by not having to share a core. That "spare" CPU thread will be running literally everything else, so it may get saturated by the kernel tasks alone.
nice +5 is more of a suggestion to "please run this task with a worse latency on a contended CPU.".
(I think I should benchmark make -j15 vs. make -j16 to see what the difference is)
Nah, I'm not that paranoid and I need the mic for calls.