Hacker News Reader

Comment by saagarjha | Hacker News Reader

A lot of time seems to go into tricking the watchdogs on single purpose machines. I heard a story once of a guy who wanted to get some computation done, but the process was being deproritized by the scheduler because it seemed like it was a hung process that kept asking for CPU time. The solution he came up with was voluntarily relinquishing compute accesd right before anyone would would check up on it, making it appear as if the process was great at sharing time with others. By doing this, he could get that one process’s instructions running something like 99% of the time.

View on HN

That's a pretty odd workaround considering that you can reserve cores to the point where not even kernel tasks run on them and then pin a single userspace thread to that core so it can run without ever being preemptively descheduled

For anyone like me who hadn't heard of this possibility before, I'll save you a few seconds of googling: https://stackoverflow.com/questions/13583146/whole-one-core-...

This wouldn't even work with the completely fair scheduler, which is the Linux default scheduler.

https://en.m.wikipedia.org/wiki/Completely_Fair_Scheduler

CFS obeys core isolation and task sets, so it would work

I was speaking of the "odd workaround", not about using cpu isolation.

> The solution he came up with was voluntarily relinquishing compute accesd right before anyone would would check up on it

I can't parse this; could you clarify? What exactly do you mean by "relinquish compute access right before anyone would check up on it"?

I can’t figure out whether it was me who wrote the words “compute access” or whether it was meant be something else and was autocorrected into that. Either way, what I meant was that the scheduler would normally come around at some fixed time, say after 1 ms, and task switch to something else if it found that the original process was still executing. Instead of letting this happen, he paused execution at 0.99 ms and told the scheduler he was done with his work. Then, he immediately resumed the process, which caused the scheduler to return control back to him.

Ohh huh wow, I'm surprised the scheduler would fall for that!

That's a pretty bad scheduler then because normally it would have moved that task to the tail of the 'ready' list for that particular priority level rather than to the front because it yielded voluntarily.

IIRC there are schedulers that dynamically adjust priority based on recent CPU usage. When a task is removed from the CPU due to its time quantum running out (as opposed to, say, making a blocking system call), that is taken as a sign that the task is relatively CPU-intensive, and its priority is reduced a little.

The idea is to give IO-bound tasks a little more priority in comparison. IO-bound tasks generally run faster if they can get another IO operation started ASAP after the last one completes, and since they're not going to hog the CPU anyway, giving them relatively higher priority is one way to do this.

Anyway, the point is that the trick works by gaming the system of priority levels. If you're at the tail of one priority level, you may be off than at the head of another.

Setting niceness to minimum wasn't enough?

Reply on news.ycombinator.com