Mail Archives: cygwin/2007/06/08/23:50:31
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<n>_*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/
- Raw text -