On 14-10-2011 19:09, Darren New wrote:
> 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.

Nor do you want him to effectively freeze it for 10 minutes by doing 
something stupid. See also below.

>> 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.

IIRC you have said that before. Actually several times and I have never 
contradicted you.

> 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.

Actually my point is that it *should not* be a user program.

>> 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.

I know that (long, long time ago I studied OS's a bit). I obviously 
meant the part of the kernel (and user level program in badly designed 
systems) that handles the CAD.

>> 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.

I disagree, there is no other user on my machine than me*. And that is 
also why your corporate webserver is a wrong example. webservers and 
user machines are something different. You should not mix those. Or at 
least the OS should behave different. Specifically in the area that we 
are discussing. CAD on a webserver should leave everything running 
(probably should even be disabled), but when I press CAD on my keyboard 
because I want control, i *want control* and I know what other processes 
I am also stopping.

*) that is at least my view of the machine. Technically it is not true.

-- 
Apparently you can afford your own dictator for less than 10 cents per 
citizen per day.

Post a reply to this message