On 13-10-2011 23:48, Darren New wrote:
> On 10/13/2011 12:55, andrel wrote:
>> So that moves the question to: why is the ctrl-alt-del handler paged out?
>
> How much of it do you want to keep in core?

To address most issues in one: you have normal operation in a system and 
emergency situations. You should not design normal operations in such a 
way that you can not handle emergencies.
What i'd do* is have the CAD handler (and a primitive task handler) in a 
small space. Preferably in one self consistent page. Immediately suspend 
all running user level programs and switch to vga to prevent the GUI 
manager from page swapping.

*) at least without thinking all problems completely through.

> I've had very little trouble
> getting the CAD handler to come up in things like Vista, but the next
> step of picking something off the menu can cause a new program to get
> launched. However, it launches task manager or some such in XP, I forget.
>
>> And the UI: why has that to be on the GUI, with all the page faults
>> that may
>> result from swapping pixels to disk? Remember we are sending a low level
>> high importance interrupt and the user knows that.
>
> Well, yes. That gets handled right away, most likely. Then it has to
> *do* something in response. I'm not sure what your point is. Your
> keystroke is of course taken into the kernel pretty much immediately.
> It's the thing that comes after I'm talking about.
>
>> I know. I am just asking if there is still a reason to handle the kernel
>> like any other user process.
>
> 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?

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

>> But, is there any reason to stop the entire kernel because of a disk
>> seek?
>
> No. Nor does that happen. Otherwise, disk seeks wouldn't continue to get
> in the way?

What apparently happens is that a program causes a page fault, possibly 
holding up the kernel because it also needs a page. After the page is 
loaded it then gets an opportunity to create another page fault before 
the scheduler hands 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.



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

Post a reply to this message