if the RAM drive itself needed to swap, we might not need the large hadron collider. sounds like black hole territory :)
On Jan 2, 8:10 pm, "John Nilsson" <j...@milsson.nu> wrote: > There was a discussion about this in the Linux community a few years ago and > some kernel developer claimed to having good results from designating a > RAM-drive to be swap. Maybe it's a good middle road between keeping the > functionality that now depends on swap and not using disk... > > BR, > John > > On Fri, Jan 2, 2009 at 6:51 AM, kirk <kirk.pepperd...@gmail.com> wrote: > > > Reinier Zwitserloot wrote: > > > Kirk: Last time I owned a windows box (I admit, that was quite a while > > > ago, but it did have XP SP2, which as far as everyone is concerned is > > > the 'latest' version of windows still, I believe), when I tried to > > > turn swap off a whole host of apps stopped working. I then configured > > > swap to be 50MB in size, and they started working again, but I didn't > > > notice any significant speedup; instead, some research showed that the > > > 50MB chunk was heavily contested. I then loaded up the old ramdisk > > > driver to create an all-RAM disk just to satisfy XP's insistence on > > > swap space, but that dropped the entire kernel down to 16-bit mode or > > > some such whacky legacy support maneuvre. A year later I downloaded an > > > XP native driver to create ram disks but never got around to trying > > > this again. > > > humm, interesting. I turned swap down to zero. The system complained but > > then I got about a 10% increase in performance and no startup pause > > while the system swapped in applications that had been swapped out. > > > The problem with swap is that it is an easy target for the systems guys > > to stuff functionality into. I learned this the hard way while working > > with Unicos (Cray unix). Cray's have no virtual memory so if you need to > > re-organize an application say after a malloc, the system would have to > > do what is known as a roll out, repack, and roll in. That is to say, the > > memory for the application would be written out to disk, and reorganized > > on the way back into memory. As you could imagine, it isn't something > > that you wanted to have happen. As you can see, being able to do that > > with swap is significantly easier. In Windows, application working set > > maintenance depends on swap. If you have applications that require a lot > > of maintenance, which it appears that you have, then I'd expect that > > turning off swap would unfortunately, not be a great idea. > > > I'm on OS X now, but I doubt turning off paging is a good idea; even > > > if I have more than enough RAM to keep all running apps in memory, > > > swapping unused bits out is still a useful exercise as it frees up RAM > > > for disk caches. I wonder if the extra effort to write RAM to swap is > > > more, or less, disk access compared to the # of accesses saved by disk > > > caches. > > > Again, Unix swap is heavily overloaded. I'm also using OSX and I've not > > even tried to turn it off. My guess is that even sleep on Mac is > > dependent upon it. A shame really 'cos I can see how performance suffers > > because of it. Solaris page alloc depends upon swap and so on... > > > It is really time to start changing this as we've got plenty of RAM and > > the gap between disk access and ram access is enormous. I guess SSD is > > coming to save the day. I've been waiting a couple of years now for > > capacity to increase and price to decrease on SSD drives. I give it > > another year for capacity and 2 for price. > > > Regards, > > Kirk > > > On Jan 1, 10:11 pm, kirk <kirk.pepperd...@gmail.com> wrote: > > > >>> A recap of issues with eating as much memory as you want: > > > >>> FACT A: OSes manage virtual memory and make it relatively hard for > > >>> userland apps to meddle and/or inspect this. > > > >>> FACT B: There's no way for the JVM to see any difference between an > > >>> app leaking memory and an app that has a legitimate use for its > > >>> continued increased memory requirements. Even if we can somehow > > >>> magically create a garbage collector that can do perfect cleanup in > > >>> near zero extra time compared to the more heuristic (pretty good but > > >>> not perfect) approach used by the current garbage collector, that > > >>> still doesn't allow us to assume that a JVM that wants more memory > > >>> should really get it. > > > >> Actually... I've written about how one should be able to automagicly > > >> detect memory leaks. Leaked objects are never accessed so if you track > > >> access, you can find them. I had some discussions with the guy working > > >> on the G1 collector and while there are some performance issues with > > >> tracking references, the scheme was workable. While sorting through > > >> details, a couple of papers came to light that detail similar schemes > > >> for automatic leak detection. If I can work out the issue with write > > >> barriers, this is something that could be dropped into OpenJDK.> FACT C: > > Its possible to do a complete garbage collect, but this takes > > > >>> precious CPU cycles. This is worth it to avoid swapping, but it is a > > >>> complete waste of time if the host computer has real memory to spare. > > >>> It's not like unused memory saves power or some such. It's effectively > > >>> a free resource, if its there. > > > >> swap is an archaic optimization where disk is traded to create more > > >> memory. Out machines now have more memory than one can shake a stick at. > > >> If you've got 2-4 gigs on your machine, I'd turn swap off. I've done > > >> this for my windows machines for a couple of years now. They have 2 gigs > > >> of ram. Occasionally I have to turn swap back on when I'm doing > > >> something that requires a lot of ram. However I normally use less than > > >> 2gigs so turning off swap is no big deal. The performance boost it gives > > >> is worth it. It also keeps my disk drive quiet which is a blessing for > > >> the batteries in my laptops. > > > >> Regards, > > >> Kirk --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to javaposse@googlegroups.com To unsubscribe from this group, send email to javaposse+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/javaposse?hl=en -~----------~----~----~----~------~----~------~--~---
