X-Spam-Check-By: sourceware.org X-YMail-OSG: udHouKIVM1lgnxIQ8czqN1Z.Bd8G74.JDrJ8Y3lqhpcJrTIvJzZ5qgfjpoamXac63EzaUrQtiI7FdN5pxohpaBPepndMkSSyHJStgA0o1qtuWdWs5A-- Message-ID: <466A2378.3080007@kringlecottage.com> Date: Fri, 08 Jun 2007 22:50:16 -0500 From: Dave & Diane User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) MIME-Version: 1.0 To: Hans Horn CC: cygwin AT cygwin DOT com Subject: Re: howto use ramdrive to speed-up cygwin References: <465CC4A2 DOT FA6D563A AT dessent DOT net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com I too would be interested in exploring this since I run cygwin and gcc on a laptop and the drive is fairly slow. I would like to move /usr/include and /usr/src/x to a ramdrive so that access is faster. Before working on a project I would simply rsync the files between the ramdrive and the persistant dir tree. I used to do this many years ago and found that it could make a difference because include files were hit so often during a build. It works well on a system where caching is less effective. I tried some Windows ramdrives a while back but found them to destabilise my system. Depending on memory constraints I'd be curious about playing some games to get /usr/bin moved there too.... Some basic info on how to create the ram drive (either within cygwin or using a reliable product outside of cygwin) would be useful. I tried creating an ext2fs using genext2fs but don't know how to mount it. As for writing scripts to effectively use it and size it etc I can do. Cheers Dave Hans Horn wrote: > Brian Dessent wrote: > >> Hans Horn wrote: >> >>> Could somebody give me a few pointers as to how to use/configure a >>> ramdrive to speed-up cygwin. >>> >>> There was a posting a few weeks ago >>> (http://sourceware.org/ml/cygwin/2007-05/msg00121.html) in which Brian >>> Dessent mentions that he is using a ramdrive for building gcc. >>> >>> Brian, would you mind disclosing a few more details about this? >> >> >> There's nothing really that exciting about what I did, it was mainly for >> running the gcc testsuite that I was experimenting with ways to make the >> time pass faster. I noticed from both the HD light and from >> sysinternals' FileMon that there was constant reading/seeking of the >> xgcc under test, so I put the whole build directory on a ramdisk. >> >> Obviously, you want to compress the ramdisk and you also have to either >> have a lot of RAM or not build all languages. Ada and Java in >> particular will kill you, as they generate a ton of temporary binaries >> when running the testsuite, and these all have full debug info by >> default. A full three stage bootstrap of all languages plus running the >> testsuite currently occupies 7.45 GB in my build dir, so obviously you >> have to do some paring down if you want to fit that all. I can't >> remember if I also moved /usr/bin onto the ramdrive or not. I think I >> did with a stripped down /usr/bin from a minimal install. The mount >> command makes it easy to relocate dirs physically but leave them in the >> same location in the posix filespace. >> >> You can also play around with removing -g from TARGET_CFLAGS and >> "bootstrap-lean" to save space, but I don't remember if those helped or >> not. I remember getting a little frustrated that there were so many >> different CFLAGS to specify and I was never able to get them all so as >> to have the result be no bloating debug info. Off the top of my head >> there's something like: >> >> BOOT_*FLAGS - for the stage 1 bootstrap >> STAGE_*FLAGS - for stage 2, 3 >> TARGET_*FLAGS - for the target libraries >> >> ...And then I think there's a few more nonstandard ones for the Ada >> runtime and perhaps a couple more that I missed. Alternatively there's >> always LDFLAGS="-s" which might have been easier. Anyway, getting back >> on topic. >> >> This is not a general purpose solution to speeding Cygwin up, it was >> just for the particular purpose of running the testsuite, which current >> takes for-frickin-ever because of whatever it is that dejagnu does that >> causes every single spawn of a test to hit the disk. You would think >> the Windows system disk cache would kick in and prevent having to do >> this sillyness, but it never did; the HD light never went out despite >> spawning the same binaries over and over again time after time. >> >> Brian >> > > Hi Brian, > thx for responding! > > I wasn't aiming for building gcc ! Instead I was rather interested in > the ramdisk aspect of that particular posting, and how I may be able > to use the idea to perhaps speedup cygwin in general (speedier > compilations are of course welcome!). > > What ramdisk software did you use? Do you have some sort of automated > setup that places /bin onto the ramdisk at boot time, and takes care > of the appropriate mount? > In case my questions sound naiive - well, that's just what they are. > I'm simply trying to find ways to make things go faster. > > thx again, > H. > > > -- > Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple > Problem reports: http://cygwin.com/problems.html > Documentation: http://cygwin.com/docs.html > FAQ: http://cygwin.com/faq/ > > -- Diane & Dave http://www.velvetstarbears.com/ http://www.kringlecottage.com/ Fortune: The difference between America and England is that the English think 100 miles is a long distance and the Americans think 100 years is a long time. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/