On 13/10/2011 12:47 AM, Darren New wrote:

> Same thing can happen if you have a whole ton of data paged out when you
> terminate the application, as AFAICT both Windows and Linux will happily
> page everything back in as it terminates the job.

What I can't figure out is why no matter how many billion bytes of 
physical RAM you have, Windows seems to swap stuff out to disk, even if 
it isn't short of physical memory. Like, if you start up Windows, open a 
few applications, walk away, and come back four hours later, as soon as 
you touch anything, it starts desperately paging all the data back into 
memory.

Um, why did it page it *out* in the first place?! I thought it was only 
supposed to swap stuff out if the space was needed for something else?

Post a reply to this message

Le 13/10/2011 10:21, Invisible a écrit :
> On 12/10/2011 05:19 PM, Darren New wrote:
>> On 10/12/2011 1:27, Invisible wrote:
>>> The "secret" part being that they didn't warn anybody "hey, we've
>>> implemented a new feature to completely disable the security of your
>>> network".
>>
>> It's no more disabling the security of your network than telnet or pop3
>> or http is. You have to tunnel out before you can get any answers back.
> 
> OK. So how is my statement that "you cannot log in to it from outside
> the building" invalidated then?

Because you assume that the firewall/Nat will protect you for that purpose.
Local teredo will send packets from inside to the outside, using UDP...
and most firewall/Nat will track that as "open a temporary route for the
UDP answer". Ergo, you will be exposed.
The nice thing, is that you are not aware that teredo might or might not
send some packets... whereas usually for telnet, you asked for the
application and the connection.

Of course, you can argue that your firewall setting is using the
explicit whitelist only approach. But usually, that does not work.
you often need whitelist + tracking of outgoing connection... and there,
you're stuck with teredo.

Have a nice day.

-- 
Software is like dirt - it costs time and money to change it and move it
around.

Just because you can't see it, it doesn't weigh anything,
and you can't drill a hole in it and stick a rivet into it doesn't mean
it's free.

Post a reply to this message

On 13-10-2011 1:47, Darren New wrote:
> On 10/12/2011 13:31, andrel wrote:
>> That is what 'surprises' me everytime. How can you design an OS where
>> it is
>> possible to prevent a task switch to a taskmanager. I assume it is
>> because
>> it wasn't designed but grown. Still, by now they should have solved
>> that, I
>> would assume.
>
> It's really not too hard. Modern desktop OSes suck at scheduling disk
> I/O, so if you're locked up because of disk I/O and you launch a new
> program, you're going to be locked up.

Might be, but why design it this way? Why has cntrl-alt-del not a higher 
priority than disk-IO and indeed any other program/process? (and on 
really modern machines: why not dedicate one core to the OS and the OS 
alone?)

>
> Sit down at a Linux machine with 16G of RAM. Create a directory with
> 1,000,000 one-block files, then type "sync", then type "rm -r xyz;sync"
> and watch Linux "lock up" for several minutes as anything that wants to
> touch the disk waits for the sync to finish.
>
> Same thing can happen if you have a whole ton of data paged out when you
> terminate the application, as AFAICT both Windows and Linux will happily
> page everything back in as it terminates the job.
>
>> BTW this is when reading a 1-2 million faces text file in into
>> Blender. And
>> when going into edit mode after that and...
>
> Disk I/O sucks in every modern desktop OS. Android also "locks up" on
> occastion for several seconds at a time, as some random program launches
> a check for something online when you're in the middle of typing
> something, for example.
>
> Contrast with CP/V, a mainframe OS from the late 1960s, that ran on a
> computer with *maybe* a 500KHz CPU running out of 256K of magnetic core
> that happily supported 40 or 50 users before you started to notice any
> slow-down. How? They had something like 30 or 40 different priority
> bumps depending on what you were waiting for and what woke you up.
> Waking up from waiting for free memory (i.e., someone else's page-out
> completing) vs waking up from waiting for pages to page in vs waking up
> from waiting for a directory entry to come from disk vs waking up when
> disk data has arrived vs etc all had different priority bumps, including
> on whether you're in core, out of core, finished your quantum last time,
> waited before your min-quantum expired last time, etc etc etc.

IIRC also the Amiga did not suffer from virtual lock up (nor do I 
remember it so badly from earlier version of MS-DOS).


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

Post a reply to this message

On 10/13/2011 1:28, Invisible wrote:
> Um, why did it page it *out* in the first place?! I thought it was only
> supposed to swap stuff out if the space was needed for something else?

Other stuff, like Windows Update or disk defragger, might have run in the 
background. Note that processes like Superfetch are supposed to minimize 
this effect. (I saw an interesting lecture on the changes they'd made to 
prevent "back from lunch syndrome.")

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

Post a reply to this message

On 10/13/2011 9:12, andrel wrote:
> Might be, but why design it this way? Why has cntrl-alt-del not a higher
> priority than disk-IO and indeed any other program/process?

Sure, but what's it going to do when it gets that keystroke? It has to fire 
up the code that handles it, presents the UI, etc.  *That* is what takes 
time to page in.

> modern machines: why not dedicate one core to the OS and the OS alone?)

The core isn't the problem. The disk is the problem, because rescheduling 
disk is slow. You can interrupt the CPU in a few hundred machine cycles. You 
can't really interrupt a disk seek.

Indeed, I suspect if Windows figured out your startup programs, figured out 
that you actually have more than enough RAM to load them all, and would just 
load the entire file sequentially instead of letting them page in on demand, 
you'd cut boot time tremendously.

> IIRC also the Amiga did not suffer from virtual lock up (nor do I remember
> it so badly from earlier version of MS-DOS).

The Amiga didn't have demand paging, so you only suffered a long shut-down 
time when you had allocated a lot of small chunks of memory and needed to 
deallocate them before exiting. That happened on occasion.

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

Post a reply to this message

On 13/10/2011 07:48 PM, Darren New wrote:
> On 10/13/2011 1:28, Invisible wrote:
>> Um, why did it page it *out* in the first place?! I thought it was only
>> supposed to swap stuff out if the space was needed for something else?
>
> Other stuff, like Windows Update or disk defragger, might have run in
> the background. Note that processes like Superfetch are supposed to
> minimize this effect.

I thought that's only in newer versions of Windows. I'm using XP here.

> (I saw an interesting lecture on the changes
> they'd made to prevent "back from lunch syndrome.")

Yeah, I vaguely remember reading something like that... Can't remember 
how I found it now.

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

On 13-10-2011 20:51, Darren New wrote:
> On 10/13/2011 9:12, andrel wrote:
>> Might be, but why design it this way? Why has cntrl-alt-del not a higher
>> priority than disk-IO and indeed any other program/process?
>
> Sure, but what's it going to do when it gets that keystroke? It has to
> fire up the code that handles it, presents the UI, etc. *That* is what
> takes time to page in.

So that moves the question to: why is the ctrl-alt-del handler paged 
out? 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.

>> modern machines: why not dedicate one core to the OS and the OS alone?)
>
> The core isn't the problem.

I know. I am just asking if there is still a reason to handle the kernel 
like any other user process.

> The disk is the problem, because
> rescheduling disk is slow. You can interrupt the CPU in a few hundred
> machine cycles. You can't really interrupt a disk seek.

But, is there any reason to stop the entire kernel because of a disk seek?

> Indeed, I suspect if Windows figured out your startup programs, figured
> out that you actually have more than enough RAM to load them all, and
> would just load the entire file sequentially instead of letting them
> page in on demand, you'd cut boot time tremendously.
>
>> IIRC also the Amiga did not suffer from virtual lock up (nor do I
>> remember
>> it so badly from earlier version of MS-DOS).
>
> The Amiga didn't have demand paging, so you only suffered a long
> shut-down time when you had allocated a lot of small chunks of memory
> and needed to deallocate them before exiting. That happened on occasion.

That is true. And on many occasions it would still be sensible to load 
no more than what you have as memory. At least I am normally only using 
one large dataset at a time. Whenever it starts paging heavily I quit 
anyway to rethink what I am doing.


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

Post a reply to this message

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

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.

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

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

Post a reply to this message

Le 2011/10/13 12:12, andrel a écrit :

> IIRC also the Amiga did not suffer from virtual lock up (nor do I
> remember it so badly from earlier version of MS-DOS).
>
>

IIRC, MS-DOS did not use paging nor virtual memory.
The main reason probably been that it was made to run on a computer 
without any hard drive but just a single floppy or possibly two, at 
least, initialy.

Some applications did implement some paging using internal or external 
modules that where used only by a single application at a time.


Alain

Post a reply to this message

On 10/13/2011 15:14, Alain wrote:
> Le 2011/10/13 12:12, andrel a écrit :
>
>> IIRC also the Amiga did not suffer from virtual lock up (nor do I
>> remember it so badly from earlier version of MS-DOS).
>>
>>
>
> IIRC, MS-DOS did not use paging nor virtual memory.

It also didn't have multi-tasking, so you didn't need to deallocate just 
the 
memory for the job that was exiting. You could just delete all the memory
 
allocated since the program started.



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

Post a reply to this message