1) mlock isn’t meant to be called on all your memory, just something that needs it to operate correctly. The situation the author described where the system comes to a halt as memory contents are paged in and out of memory/disk is (subjectively) worse when the only option is for the OOM killer to begin reaping processes everywhere (which would happen if all apps took this advice).
2) the following excerpt is not how any sane modern OS scheduler works:
> Imagine you have multiple background process running at 100% CPU, then a UI event comes in to the active UI application. The operating system may block for 100ms * N before allowing the UI application to process the event, where N is the number of competing background processes, potentially causing a delayed response to the user that violates the real-time constraint
Modern schedulers calculate priority based off whether the process/thread yielded its remaining execution time in the previous round or was forcibly evicted. Background processes are additionally run at a penalty. The foreground window (on OSes with internal knowledge of such a thing) or terminal owner in the current login session group gets a priority boost. Threads blocked waiting for input events get a massive priority boost.
(But the point stands and it might be a whole lot longer than n * 100ms if drivers or kernel modules are doing stuff.)