On 10/14/2011 9:29, andrel wrote:
> What i'd do* is have the CAD handler (and a primitive task handler) in a
> small space.

I think this is more like what post-XP OSes do.

> Immediately suspend all running user level programs

Always mount a scratch monkey.

You really don't want the guy at the keyboard hitting CAD and suspending 
your corporate web server.

> and switch to vga to prevent the GUI manager
> from page swapping.

I don't think it goes that far, but certainly the newer CAD handlers could 
do something like that, visually speaking.

>> The problem is not in the kernel's response. It's the fact that the
>> complaint is the task manager takes a long time to come up, preventing
>> you from killing the task.
>
> Because the task manager is implemented at the same priority level as Blender?

No it isn't. The problem isn't with the CPU. The problem is with the disk. 
Now, the problem is that when the task manager pages in a page, now it's 
going to run long enough for Blender to ask for a page. Now you've started a 
disk seek, which you can't satisfy or abort before the task manager needs 
its next page.

One simple solution might be to page in the entire task-manager task rather 
than doing it on demand, but that's exactly the sort of "disk scheduling 
sucks in modern desktop OSes" that I'm talking about.

>> In UNIX terms, it's like complaining that /bin/kill takes a long time to
>> load when the system is thrashing, and you asking why the kill() kernel
>> trap would be paged out in the first place.
>
> Can that happen?

No. That's my point. You're complaining CAD is unresponsive, when the 
problem is that the user-level program you're trying to launch via CAD is 
unresponsive.

> What apparently happens is that a program causes a page fault, possibly
> holding up the kernel because it also needs a page.

The kernel doesn't need a page. That's why it's the kernel. The task manager 
needs the page. The task manager is a user-level program.

Analogously, kill(1) doesn't need a page. But /bin/kill does, because it's a 
user-level program, and it's the quickest way to actually invoke kill(1).

> After the page is loaded
> it then gets an opportunity to create another page fault before the
> scheduler hands control back to the kernel.

A page fault *is* handing control back to the kernel.

> My reaction as a user is: 'hello, I just pressed CAD, stop all other
> programs and process that interrupt before doing anything else!' Something
> is terribly wrong with the priorities of my machine.

Well, first, CAD is used for lots of stuff besides "I have too many page 
faults". Second, you don't want anyone sitting at the keyboard to shut down 
any process running on your machine. These *are* multi-user machines, you know.

-- 
Darren New, San Diego CA, USA (PST)
   How come I never get only one kudo?

Post a reply to this message