A hint: If it will run on Vista, it will almost certainly run on 7. The API did not change between.
-----Original Message----- From: boinc_dev [mailto:[email protected]] On Behalf Of Robert Miles Sent: Thursday, April 18, 2013 1:28 AM To: [email protected] Subject: Re: [boinc_dev] A problem with memory used calculations, at, least for 64-bit Windows Vista I currently have three of the The Lattice Project 3.11 GB workunits running on my Windows 7 desktop with 16 GB RAM and BOINC allowed to use 80% of it. On the other hand, my Windows Vista desktop with 8 GB RAM and BOINC allowed to use 40% of it has not been able to complete such a The Lattice Project workunit successfully for months. Allowing BOINC to use a larger fraction of the memory almost stops the execution of any programs that use the keyboard. The 3.11 GB workunits just cannot get enough memory to run properly while a few 32-bit workunits are running, often one from Rosetta@Home that uses around 500 MB, not counting any SYSWOW64 modules. A few other differences noticed: The SYSWOW64 modules for Windows 7 (shown as svchost.exe in the Windows Task Manager if Show processes for all users is enabled) are only a fraction of the size of those for Windows Vista, which suggests that Windows 7 has them broken into smaller pieces so that it does not need to load as much into memory when only a fraction of each Windows Vista SYSWOW64 modules are used. In other words, there is less need for separate limits for 32-bit memory space and 64-bit memory space under Windows 7 than under Windows Vista, because Windows 7 is more memory-efficient at running 32-bit programs. Looks like a good reason to install Windows 7 on the 8 GB desktop AFTER I'm no longer running any programs that aren't Windows 7 compatible. Perhaps a way to tell the BOINC client to request ONLY 64-bit workunits, or ONLY 32-bit workunits, would be a good temporary workaround for this problem? > > Date: Sun, 14 Apr 2013 20:17:03 -0500 > From: Robert Miles <[email protected]> > Subject: Re: [boinc_dev] A problem with memory used calculations, at > least for 64-bit Windows Vista > > Not the main point I was discussing. I was writing mostly about HOW MUCH > is loaded into memory, not where it is loaded. 32-bit workunits under > 64-bit > Windows just won't run without any SYSWOW64 modules in memory, and > usually need about as much memory for the SYSWOW64 modules they use as > for the 32-bit application program. > > -----Reply To ----- > Date: Fri, 12 Apr 2013 16:37:48 +0000 > From: "McLeod, John" <[email protected]> > To: Robert Miles <[email protected]>, > "[email protected]" <[email protected]> > Subject: Re: [boinc_dev] A problem with memory used calculations, at > least for 64-bit Windows Vista > > Where things are loaded in memory should have no effect on reloading after a > checkpoint. No application should ever store a memory pointer into a file. > If they do, then there is a problem with the checkpointing of that > application. > > -----Original Message----- > From: boinc_dev [mailto:[email protected]] On Behalf Of > Robert Miles > Sent: Friday, April 12, 2013 11:56 AM > To: [email protected] > Subject: [boinc_dev] A problem with memory used calculations, at least for > 64-bit Windows Vista > > I've noticed the BOINC has a problem with memory used calculations under > 64-bit Windows, when running a mix of 32-bit workunits and 64-bit > workunits. It does not include the SYSWOW64 modules in use by the > 32-bit workunits (possibly because they are listed as being run by > System and are not in the 32-bit memory space). > > These SYSWOW64 modules roughly double the amount of 64-bit memory space > needed to run these 32-bit workunits. > > As a result, a 64-bit workunit can check the memory available, decide > that it's enough, and start running. However, if the total RAM is 8 GB > or less, the doubling of space occupied by 32-bit workunits can exhaust > the free memory available in 64-bit memory space before the 64-bit > workunit reaches its first checkpoint, which puts the 64-bit workunit > into Waiting to run state and can also push it into virtual memory. If > Windows does not restore it to the same addresses in 64-bit memory when > restoring it from virtual memory (I believe I've read that it does not) > and the application is not sufficiently location-independent, BOINC will > restart this workunit from the beginning, and probably encounter the > same problem again, over and over. > > Seen with: > 64-bit Windows Vista Home Premium SP2 (some of the programs I run aren't > compatible with later Windows versions) > 8 GB RAM, but BOINC limited to using 40% of it to avoid drastic > slowdowns of non-BOINC 32-bit programs, including one of the programs in > the path for accepting keyboard input; motherboard will not hold any > more RAM > BOINC 7.0.28, but also seen with some earlier 7.0.* versions; haven't > tried any versions after 7.0.28 > A The Lattice Project workunit trying to use about 3.1 GB of 64-bit > memory, but also 32-bit workunits from other projects trying to use > about 300 MB of 32-bit memory (not counting the SYSWOW64 modules) > > A possible fix I've thought of: Modify BOINC to use separate memory > limits for 64-bit memory space and for 32-bit memory space. Count the > 32-bit workunits, but not the SYSWOW64 modules they use, against the > limit on 32-bit memory space. Count the 64-bit workunits, the 32-bit > workunits, and the SYSWOW64 modules used by the 32-bit workunits, > against the limit on 64-bit memory space. > > I've seen nothing indicating whether 64-bit versions of Windows other > than Vista also need this fix, and nothing indicating whether 64-bit > operating systems other than Windows need it. > _______________________________________________ boinc_dev mailing list [email protected] http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev To unsubscribe, visit the above URL and (near bottom of page) enter your email address. _______________________________________________ boinc_dev mailing list [email protected] http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev To unsubscribe, visit the above URL and (near bottom of page) enter your email address.
