Jihad needs scientists
in [Design]
|
From: Ken Smith on 24 Feb 2007 11:51 In article <erpeao$8qk_001(a)s934.apx1.sbo.ma.dialup.rcn.com>, <jmfbahciv(a)aol.com> wrote: >In article <ermuqc$rph$3(a)blue.rahul.net>, > kensmith(a)green.rahul.net (Ken Smith) wrote: >>In article <ermlh8$8ss_012(a)s774.apx1.sbo.ma.dialup.rcn.com>, >> <jmfbahciv(a)aol.com> wrote: >>>In article <erhnfn$em5$5(a)blue.rahul.net>, >>> kensmith(a)green.rahul.net (Ken Smith) wrote: >>>>In article <erhd4t$8qk_001(a)s916.apx1.sbo.ma.dialup.rcn.com>, >>>> <jmfbahciv(a)aol.com> wrote: >>>>>In article <i70nt25k4ubuvllr029cun9ebu1e1bng0a(a)4ax.com>, >>>>> MassiveProng <MassiveProng(a)thebarattheendoftheuniverse.org> wrote: >>>>>>On Mon, 19 Feb 07 13:29:06 GMT, jmfbahciv(a)aol.com Gave us: >>>>>> >>>>>>>Not at all. OSes were handling the above problems in the 60s. >>>>>>>The reason virtual memory was invented was to solve the above >>>>>>>problem. >>>>>>> >>>>>> The swapping, in this case, CAUSES the interference. >>>>> >>>>>That has to do with severe memory management problems. >>>> >>>>No, it is just part of the overhead of doing VM. >>> >>>Nope. VM doesn't have to swap. Swapping is done to make >>>room so a memory request by another task can be serviced. >> >>You said "nope" and then confirmed that my statement was correct. >>Swapping needs to happen if you need more virtual RAM than there is real >>RAM. To be able to swap, the code for doing the swapping must always be >>in the real RAM. As a result, there is code overhead in having a VM >>system. There is also a speed overhead when swapping happens. The OS >>uses some amount of CPU time on the taks switching needed to make VM do >>the swap. > >VM isn't swapping. VM allows the OS to manage smaller chunks >of memory rather than segments. That is completely and totally worng. "Virtual memory" means quite literally "memory that is not real". MVT360 managed memory on a IIRC 4K page basis. This certainly did not qualify as a virtual memory system. >>>I don't know why but people often confuse virtual memory >>>addressing with swapping. The two are separate. >> >>No, you are confused on the issue of needing to swap. > >No, I'm not. You are. It seems that your confusion runs much deeper than that. You seem not to understand what "virtual" means. > >> We have already >>discussed why the swapping is needed. In the case we are talking about, >>there is more that needs to be in memory than there is physical RAM. > >You are now talking about two kinds of memory. Yup, you don't know what "virtual" means. [....] >>No, I am not. The case under discussion was quite specific. There were >>two large tasks which individually would fit into physical memory but that >>added up to more than would fit. If the two were loaded at the same time, >>the results would be later in coming than if you ran them one after the >>other. > >You keep assuming that all the code of both had to be in core even >if it wasn't going to executed. If you want them both to be running, they both have to be in core. If one is not in core, you are running them one after the other which is faster as we have already tried to explain to you. [....] >>No it was mostly about RAM. The IBM360 can only address 16M. Running a >>copy MVS couldn't get around this hard limit. If there was not enough >>address space to fit all the code or data, something had to be rolled out >>and processed later. > >That's why code segments and buffered mode I/O were invented. That isn't ever wrong, it is so far off the mark. You really don't understand this do you? >>No. In a page based MMU, you don't have this issue. When you only have a >>by segment memory management, you end up with gaps in the memory space. >>Compacting is a method for gathering the smaller gaps together to make >>bigger free blocks. It requires that the data be moved. > >There are two major methods to do this job: swapping and shuffling. >When the swapping device was very slow the last thing picked >to do in any memory manager would have been swapping. Shuffling >had its own quirks and CATCH-22s. You are obviously making stuff up. "swapping" has nothing to do with "compacting". >Note that you do not have to swap code if it's reentrant; you can >overwrite it in the RAM if the code segment resides on a device >whose retrieval speed is equiavlent to memory fetches. Code does not have to be reentrant to be able to reread the code from the source media. All that must be true is that the code space is not used to store things. On a Windows machine, the option of rereading the code is never taken. It would be very unusual for it to be able to be done on any other machine either. Swap volumes are always going to be the faster type of drive. -- -- kensmith(a)rahul.net forging knowledge
From: MassiveProng on 24 Feb 2007 12:15 On Sat, 24 Feb 07 12:31:04 GMT, jmfbahciv(a)aol.com Gave us: >You are not talking about swapping; you are talking about the >working set of pages. You do NOT have to swap code if the >storage disk is as fast as the swapping disk. Bwuahahahahahahahaahahahahahaah!
From: MassiveProng on 24 Feb 2007 12:16 On Sat, 24 Feb 07 13:24:40 GMT, jmfbahciv(a)aol.com Gave us: >>No, you are confused on the issue of needing to swap. > >No, I'm not. You are. I KNOW YOU ARE, BUT WHAT AM I?!!! Bwuahahahahahahah! Priceless!
From: MassiveProng on 24 Feb 2007 12:20 On Sat, 24 Feb 07 13:24:40 GMT, jmfbahciv(a)aol.com Gave us: > >Note that you do not have to swap code if it's reentrant; you can >overwrite it in the RAM if the code segment resides on a device >whose retrieval speed is equiavlent to memory fetches. OTOH, >you do have to preserve data. RULES: 2 500MB code blocks that are in the form of a FILE (FileA, FileB) that has to be processed in 500MB RAM. You're solution: Run (we call this the name of the executable) both together on the machine at the same time. The REAL solution: A simple batch file. run FileA run FileB
From: MassiveProng on 24 Feb 2007 12:23
On Sat, 24 Feb 07 13:44:56 GMT, jmfbahciv(a)aol.com Gave us: >Using your method, a restore would have to start with Backup Tape >#1, then #2, then #3, ....finishing with the last backup tape made. >If you have been doing this for three years, you have 1000 tapes >to restore. Nobody said ANYTHING about tape based magnetic storage. You are one old dip, I'll say that. |