This is more of a theoretical question as I'm trying to understand how the kernel scheduler works (but also I've been having hung_task issues while mid-priority RT tasks are running - and also there are swapper processes in the CPU dumps). I am using the kernel with the RT patch (fully preemptive kernel).
If the process goes into a D state (due to a sys_read from RAM, e.g. from procfs), is it possible for it to be preempted by higher priority RT tasks (maybe multiple times) so it will remain into the D state and then resume reading? I am unsure how this works if there is RAM read in question.
So, what happens next, the process stuck in a D state is actually in uninterruptible sleep, and is it waiting to be rescheduled if it is preempted? Can it be rescheduled on a different CPU? Especially if there are swapper tasks present, wouldn't they do something to resume the process that was in D state?
I am a bit confused by all this, as I have processes reading just from RAM, and somehow other tasks try to get rt-mutex locks from it and then I get hung_task issue. But there are always some (seemingly) idle CPU cores. Why would a RAM read take so long? Sometimes RCU thread also gets hung while waiting for a lock from a process doing a sys_read from procfs.
I know it's a lot of questions, but I need to connect the pieces of the puzzle in my head somehow. Any help is appreciated.
Thank you in advance. :)
