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: Scott Lurndal on 5 Mar 2010 16:44 nmm1(a)cam.ac.uk writes: >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. What relocation? I don't recall any relocation happening either in SVR4/Unixware or Linux on executable pages (other than PLT and GOT updates which by definition will be paged, not restored from the ELF executable). scott
From: Tim McCaffrey on 5 Mar 2010 16:50 In article <hmpnr6$iql$1(a)news.eternal-september.org>, SFuld(a)alumni.cmu.edu.invalid says... > >On 3/4/2010 3:43 PM, Scott Lurndal wrote: >> Morten Reistad<first(a)last.name> writes: >>> In article<hmoo7o$460$1(a)speranza.aioe.org>, Noob<root(a)127.0.0.1> wrote: >> >>>> In short, will widely-available SSDs require OS designers to make >>>> large changes, or is the current infrastructure generic enough? >>> >>> This is old news. I have been deploying such systems for 7 years now. >> >> SSD's have been available for over 25 years in the mainframe world, some >> using battery backed DRAM, some using much more expensive SRAM. > >Yup! But closer to 35 years and include in the technology choices, CCD >memories, bubble memory and even core! > If you are going to use it for a paging device, it makes more sense to use some cheap DRAM technology than try to use a Flash based device. For instance, if you could use a PCIe x1 (v2.0) card (using, say, 133 Mhz SDRAMs), you get 400 MB/s Read/Write with no need for a TRIM command, etc. SDRAMs are just an example. For this sort of application, you want the cheapest, densest, DRAM you can find. It should still be faster than Flash. And since it is used for paging, you don't need to worry about data going away when the power goes off. Be great for temp files (browser cache, etc) as well. (and this is looking more like the ECS discussion....) - Tim
From: nmm1 on 5 Mar 2010 16:58 In article <oXekn.636790$L8.618236(a)news.usenetserver.com>, Scott Lurndal <slp53(a)pacbell.net> 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. > >What relocation? I don't recall any relocation happening either in >SVR4/Unixware or Linux on executable pages (other than PLT and GOT >updates which by definition will be paged, not restored from the >ELF executable). Ah, so you never used dynamic libraries. However, a more important point is that not all systems are Unix-like, and many of those rely on relocation to provide the facilities that Unix doesn't. Regards, Nick Maclaren.
From: Scott Lurndal on 5 Mar 2010 18:16 nmm1(a)cam.ac.uk writes: >In article <oXekn.636790$L8.618236(a)news.usenetserver.com>, >Scott Lurndal <slp53(a)pacbell.net> 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. >> >>What relocation? I don't recall any relocation happening either in >>SVR4/Unixware or Linux on executable pages (other than PLT and GOT >>updates which by definition will be paged, not restored from the >>ELF executable). > >Ah, so you never used dynamic libraries. Yes, extensively. The GOT is the global-offset-table that is used to link the shared object with the base executable for data items. It's updated by the run-time linker when the shared object is loaded (at exec() and dlopen()). The PLT (procedure linkage table) is used for functions, and this is updated on 'first touch'. The shared object code itself is position independent (PIC). In both cases, they are placed in writable memory regions that will be paged to the swap file, not restored from the .so or ELF executable. The only time "object" relocation is done is when the executable is linked from the relocatable object files (.o) into an elf executable or a shared object. Linux DLM's are relocated when loaded, but kernel code is not paged. > >However, a more important point is that not all systems are >Unix-like, and many of those rely on relocation to provide the >facilities that Unix doesn't. I was posting this via "comp.UNIX.programmer" and didn't see the comp.arch xpost. Certainly in other environments YMMV. scott
From: Ian Collins on 7 Mar 2010 03:42
Noob wrote: > > Given the typical Unix directory structure: > http://en.wikipedia.org/wiki/Unix_directory_structure > which directories should go the SSD and which to the HDD? > > bin and sbin => SSD > usr => SSD probably > home => HDD > etc ?? => not modified often ?? SSD perhaps > var ?? > > In short, will widely-available SSDs require OS designers to make > large changes, or is the current infrastructure generic enough? Mixing SSDs and slower spinning drives is quite common on (Open)Solaris systems. ZFS can use SSDs for cache and log devices. This approach of combining different storage technologies in a single pool to give the best price / performance is the way to go. -- Ian Collins |