Impact of solid-state drives
in [Unix Programming]
|
Prev: gethostbyname doesn't accept IPv6 addresses
Next: 7 x = ."It's" IF ." " ELSE ."not " THEN ."equal"
From: Anne & Lynn Wheeler on 5 Mar 2010 09:35 Chris Friesen <cbf123(a)mail.usask.ca> writes: > Of course it's better not to swap. However, given a specific machine > and a specific workload, there may be no possible way to fit both the > code and the data set into RAM at the same time. > > If swapping out a page of code that gets executed extremely rarely > allows the data set to fit in RAM and the app runs 10x faster, I'm all > for paging executable code. recent reference to somebody's decision to bias page replacement algorithm to non-changed pages ... (i.e. less effort, since replaced paged didn't have to be written out first, valid copy was still on paging device) ... was that way for nearly a decade (most of the 70s) before they realized that they were replacing high-use, shared executable code before much lower-use, private data pages http://www.garlic.com/~lynn/2010d.html#78 LPARs: More or Less? there was some facetious reference about getting paid for doing it the wrong way ... so later can get award for fixing the problem. http://www.garlic.com/~lynn/2010d.html#78 LPARs: More or Less? more recent thread about performance issues related to paging microcode http://www.garlic.com/~lynn/2010e.html#34 Need tool to zap core http://www.garlic.com/~lynn/2010e.html#44 Need tool to zap core -- 42yrs virtualization experience (since Jan68), online at home since Mar1970
From: Ken Hagan on 5 Mar 2010 11:47 On Fri, 05 Mar 2010 10:12:31 -0000, Noob <root(a)127.0.0.1> wrote: > What happens when there's "just not enough RAM"(TM)(R)? What happens when there is "just not enough page file" ? I think the point being made here is that one shouldn't attempt to optimise the system design for efficient paging. We can all imagine loads that exceed available memory and in the real world you will meet them occasionally, but for the past decade or two it has been quite reasonable to put "enough RAM" in the machine for 99% of tasks and disk speeds (especially for random access) have been so far below even DRAM speeds that a page fault is "game over" as far as optimisation is concerned.
From: Scott Lurndal on 5 Mar 2010 12:40 Chris Friesen <cbf123(a)mail.usask.ca> writes: >On 03/04/2010 12:35 PM, Scott Lurndal wrote: > >> It's "Better" (for all metrics) to not swap. > >> It never makes sense to page executable code. > >Of course it's better not to swap. However, given a specific machine >and a specific workload, there may be no possible way to fit both the >code and the data set into RAM at the same time. > >If swapping out a page of code that gets executed extremely rarely >allows the data set to fit in RAM and the app runs 10x faster, I'm all >for paging executable code. I should have elaborated. I meant "It never makes sense to page executable code to the page/swapfile". (Although, as pointed out above, it make make some sense if the executable itself resides on some slow storage, such as optical media or floppy). scott
From: nmm1 on 5 Mar 2010 13:19 In article <8mbkn.151094$ZQ3.119406(a)news.usenetserver.com>, Scott Lurndal <slp53(a)pacbell.net> wrote: >Chris Friesen <cbf123(a)mail.usask.ca> writes: >>On 03/04/2010 12:35 PM, Scott Lurndal wrote: >> >>> It's "Better" (for all metrics) to not swap. >> >>> It never makes sense to page executable code. >> >>Of course it's better not to swap. However, given a specific machine >>and a specific workload, there may be no possible way to fit both the >>code and the data set into RAM at the same time. >> >>If swapping out a page of code that gets executed extremely rarely >>allows the data set to fit in RAM and the app runs 10x faster, I'm all >>for paging executable code. > >I should have elaborated. I meant > > "It never makes sense to page executable code to the page/swapfile". > > (Although, as pointed out above, it make make some sense if the executable > itself resides on some slow storage, such as optical media or floppy). And, also as previously pointed out, it makes sense if relocation is expensive compared to paging. Or the system allows in-use executables to be updated. And probably under other circumstances. Regards, Nick Maclaren.
From: Robert Myers on 5 Mar 2010 14:06
On Mar 5, 11:47 am, "Ken Hagan" <K.Ha...(a)thermoteknix.com> wrote: > On Fri, 05 Mar 2010 10:12:31 -0000, Noob <r...(a)127.0.0.1> wrote: > > What happens when there's "just not enough RAM"(TM)(R)? > > What happens when there is "just not enough page file" ? > > I think the point being made here is that one shouldn't attempt to > optimise the system design for efficient paging. We can all imagine loads > that exceed available memory and in the real world you will meet them > occasionally, but for the past decade or two it has been quite reasonable > to put "enough RAM" in the machine for 99% of tasks and disk speeds > (especially for random access) have been so far below even DRAM speeds > that a page fault is "game over" as far as optimisation is concerned. But maybe not forever. One way of eliminating the teeth-grinding chaos of current machines trying to do many different things at once is to make greater use of virtualization, so as to provide better isolation between different and probably competing activities. The inevitable pressure from increasing use of virtualization will be for more and more memory, which may bring back swap space as an important player. Robert. |