I don't remember seeing this problem back when I was still seeing any rosetta workunits. However, one of the mini-rosetta processes running now has peaked at 942 KB used. Rosetta@Home has never made it clear if they've completely stopped generating rosetta workunits, but it's been months since I've seen any.
Where do I find Process Explorer? 64-bit Windows Vista Home Premium SP2 does not seem to include anything with that name. I did find Resource Monitor, but the results from it appear to imply that three workunits are making heavy use of the three CPU cores I allow BOINC to use, something else is using about half the time on the fourth CPU core, and nothing else it will display is in heavy use. - Robert Miles . > . > ---- > Date: Fri, 27 Apr 2012 21:09:39 -0400 > From: "Rom Walton"<[email protected]> > Subject: Re: [boinc_dev] boinc_dev Digest, Vol 95, Issue 23 > To: "Robert Miles"<[email protected]>, > <[email protected]> > > Mini-rosetta or just rosetta? > > Maybe there is a resource that is shared between all of them that can be > identified through Process Explorer. > > ----- Rom > > -----Original Message----- > From: Robert Miles [mailto:[email protected]] > Sent: Friday, April 27, 2012 9:06 PM > To: [email protected] > Cc: Rom Walton > Subject: Re: boinc_dev Digest, Vol 95, Issue 23 > > The applications typically running during such slowdowns are a few of > the more memory-hungry 32-bit workunit application programs, such as > those from Rosetta@Home, a few of the svchost.exe programs for SysWOW64 > (64-bit), the dwm.exe (64-bit) program that lets me look at the > resources used, and a rather small kbd.exe (32-bit) program that does > some of the keyboard input processing. There's usually a variety of > other programs, but nothing that appears to have relevant features. > > - Robert Miles > . >> . >> >> ----- >> >> Date: Fri, 27 Apr 2012 18:06:31 -0400 >> From: "Rom Walton"<[email protected]> >> Subject: Re: [boinc_dev] boinc_dev Digest, Vol 95, Issue 22 >> >> I'm that person. >> >> Unlike 16-bit applications back in the day that expected to all exist >> within the same address space, 32-bit applications have always existed >> within separate address spaces. You actually have to go through great >> lengths to share information/memory between processes. >> >> BOINC uses the generic CreateProcess/CreateProcessAsUser Windows API >> to launch 32-bit/64-bit applications. Windows handles the details as >> to whether or not to use WOW64 based on the executable header. In any >> case, both 32-bit and 64-bit applications expect to exist within their >> own virtualized address space by default. >> >> Which applications typically run when you experience this slow down >> issue you are experiencing? >> >> ----- Rom >> >> -----Original Message----- >> From: Robert Miles [mailto:[email protected]] >> Sent: Friday, April 27, 2012 5:55 PM >> To: [email protected] >> Cc: Rom Walton >> Subject: Re: boinc_dev Digest, Vol 95, Issue 22 >> >> It looks to me more like this is saying that 64-bit versions on >> Windows ALLOW methods of starting processes that will put each 32-bit >> process in a separate 32-bit address space, but nothing about whether >> BOINC actually uses these methods. Could we bring someone more >> familiar with the internals of 64-bit Windows BOINC clients into this >> discussion to say more about whether the clients actually use such > methods? >> - Robert Miles >> >> . >>> -------- >>> >>> Date: Fri, 27 Apr 2012 13:51:10 -0400 >>> From: "Rom Walton"<[email protected]> >>> Subject: Re: [boinc_dev] boinc_dev Digest, Vol 95, Issue 20 >>> To:<[email protected]>, "Robert Miles" >>> <[email protected]> >>> >>> Microsoft provides a good starting place for this topic: >>> http://msdn.microsoft.com/en-us/library/aa384249(v=vs.85).aspx >>> >>>> From the looks of it, each process (32-bit/64-bit) is contained >>>> within a >>> separate virtualized 64-bit address space. 32-bit applications load >>> the additional WOW64 binaries to handle thunking. kernel handles >>> only contain 32-bits of relevant information so that they can be >>> truncated for use by 32-bit applications. >>> >>> ----- Rom >>> >>> -----Original Message----- >>> From: [email protected] >>> [mailto:[email protected]] On Behalf Of >>> [email protected] >>> Sent: Friday, April 27, 2012 1:24 PM >>> To: Robert Miles >>> Cc: [email protected]; [email protected] >>> Subject: Re: [boinc_dev] boinc_dev Digest, Vol 95, Issue 20 >>> >>> I am going to speculate for a bit. >>> >>> If 32 bit process handles do not translate from 32 bit apartment to a >>> different 32 bit apartment, then >>> 1) 32 bit processes started by a 32 bit process will have to come >>> out of the same 4GB process space (yes, this includes the video space >>> so some less space for programs). It may be true only if the parent >>> process stores the process handle of the child. >>> and >>> 2) A 32 bit process started by a 64 bit process can get a new 4GB >>> process space. >>> >>> jm7 >>> >>> >>> |------------> >>> | From: | >>> |------------> >>> >>>> -------------------------------------------------------------------- >>>> - >>>> -- >>> --------------------------------------------------------------------- >>> - >>> -- >>> ---| >>> |Robert Miles<[email protected]> >>> | >>> >>>> -------------------------------------------------------------------- >>>> - >>>> -- >>> --------------------------------------------------------------------- >>> - >>> -- >>> ---| >>> |------------> >>> | To: | >>> |------------> >>> >>>> -------------------------------------------------------------------- >>>> - >>>> -- >>> --------------------------------------------------------------------- >>> - >>> -- >>> ---| >>> |<[email protected]> >>> | >>> >>>> -------------------------------------------------------------------- >>>> - >>>> -- >>> --------------------------------------------------------------------- >>> - >>> -- >>> ---| >>> |------------> >>> | Date: | >>> |------------> >>> >>>> -------------------------------------------------------------------- >>>> - >>>> -- >>> --------------------------------------------------------------------- >>> - >>> -- >>> ---| >>> |04/27/2012 12:33 PM >>> | >>> >>>> -------------------------------------------------------------------- >>>> - >>>> -- >>> --------------------------------------------------------------------- >>> - >>> -- >>> ---| >>> |------------> >>> | Subject: | >>> |------------> >>> >>>> -------------------------------------------------------------------- >>>> - >>>> -- >>> --------------------------------------------------------------------- >>> - >>> -- >>> ---| >>> |Re: [boinc_dev] boinc_dev Digest, Vol 95, Issue 20 >>> | >>> >>>> -------------------------------------------------------------------- >>>> - >>>> -- >>> --------------------------------------------------------------------- >>> - >>> -- >>> ---| >>> |------------> >>> | Sent by: | >>> |------------> >>> >>>> -------------------------------------------------------------------- >>>> - >>>> -- >>> --------------------------------------------------------------------- >>> - >>> -- >>> ---| >>> |<[email protected]> >>> | >>> >>>> -------------------------------------------------------------------- >>>> - >>>> -- >>> --------------------------------------------------------------------- >>> - >>> -- >>> ---| >>> >>> >>> >>> >>> >>> Then why have I sometimes seen 7 GB used at once when most of the >>> programs running were 64-bit non-BOINC programs, and without such a >>> drastic slowdown? >>> >>> By the way, earlier today, I saw about 4.5 GB of 32-bit programs >>> running at once, but enough were non-BOINC to suggest that the 3.5 GB >>> limit I've seen applies mostly to BOINC programs. Could this mean >>> that 64-bit Windows BOINC crowds all the 32-bit applications it >>> starts into a single 32-bit memoryspace, even if running under a >>> version of Windows that does not force such a restriction? >>> If so, the only other 32-bit programs affected could be those that >>> happen to run on the same CPU core as the main BOINC client >> executable. >>> If that's the case, BOINC needs the ability to set the memory limit >>> for the sum of all 32-bit executables it runs to be less than the >>> total it can use if 64-bit executables are included. >>> >>> I haven't found a good chance yet to check if something similar >>> happens if all the workunits available are 64-bit, since such >>> workunits are still rather scarce. >>> >>> - Robert Miles >>> >>> . >>>> ------------------------------ >>>> >>>> Message: 6 >>>> Date: Fri, 27 Apr 2012 10:23:01 -0400 >>>> From: "Rom Walton"<[email protected]> >>>> Subject: Re: [boinc_dev] 32-bit workunits under 64-bit Windows >>>> To: "Robert Miles"<[email protected]>, >>>> <[email protected]> >>>> Message-ID: >>>> >>> <[email protected]> >>>> Content-Type: text/plain; charset="us-ascii" >>>> >>>> Sounds more like paging than anything else. Each process is >>>> independent of each other. >>>> >>>> 32-bit processes are not treated like 16-bit tasks running under >>>> NTVDM back in the day. >>>> >>>> I suspect you'll find that the same thing happens when you start a >>>> few 64-bit processes that use a similar amount of memory. >>>> >>>> ----- Rom >>>> >>>> -----Original Message----- >>>> From: Robert Miles [mailto:[email protected]] >>>> Sent: Friday, April 27, 2012 9:57 AM >>>> To: [email protected] >>>> Cc: Rom Walton >>>> Subject: Re: [boinc_dev] 32-bit workunits under 64-bit Windows >>>> >>>> The 3.5 GB is not for just one process. It's the total for all >>>> 32-bit processes running at once, most of which are workunit >>> applications. >>>> The hard drive is a little busy at such times - enough for the hard >>>> drive light to flash perhaps once a second. >>>> >>>> The best I can tell, at least one of the applications HP supplied >>>> for processing keyboard input is also 32-bit, and therefore more >>>> likely to be affected by crowding too much into the same 32-bit > memoryspace. >>>> - Robert Miles >>>> >>>> ----- >>>> Date: Wed, 25 Apr 2012 15:40:51 -0400 >>>> From: "Rom Walton"<[email protected]> >>>> Subject: Re: [boinc_dev] 32-bit workunits under 64-bit Windows >>>> >>>> I'm confused. On Windows, out of the box, the largest amount of >>>> memory a single 32-bit program can allocate is 2GB (3GB with a >>>> special boot option). I believe that is even true on a 64-bit > system. >>>> When your system starts to slow down, is the hard drive busy? It >>>> sounds like what you are experiencing is paging related. >>>> >>>> ----- Rom >>>> >>>> -----Original Message----- >>>> From: [email protected] >>>> [mailto:[email protected]] On Behalf Of Robert >>>> Miles >>>> Sent: Sunday, April 22, 2012 5:36 PM >>>> To: [email protected] >>>> Subject: [boinc_dev] 32-bit workunits under 64-bit Windows >>>> >>>> I've found that my computer tends to slow down user response quite a >>>> bit as the total memory used by 32-bit workunits and other 32-bit >>>> programs approaches 3.5 GB, as I'd expect if all 32-bit programs >>>> must fit within a single 4 GB memoryspace even though the computer >>>> has 8 GB of memory installed. Could you check if this is actually >>>> what's happening, especially on 64-bit versions of Windows with the >>>> lower limits on the total amount of memory they can use? If so, can >>>> you find a way to give each 32-bit workunit a separate 4 GB >>>> memoryspace, even if some of it is shared with other workunits? >>>> >>>> Another possibility is that the portions of the SysWOW64 software >>>> needed to run 32-bit programs is similar in size to the programs >>>> that need it, and therefore you should consider counting SysWOW64 >>>> software against the memory limit allowed for BOINC. Or just count >>>> 32-bit workunits twice against the limit, but 64-bit workunits only > once. >>>> Or even allow setting the limit for 32-bit BOINC software and >>>> workunits to be lower than the total amount of memory BOINC can use. >>>> >>>> I'm using 64-bit Windows Vista Home Premium SP2 on that computer. I >>>> haven't found any way to check which if either of the above >>>> possibilities is correct. Currently using BOINC 7.0.25, but I have >>>> seen the same problem on earlier versions back to at least some of >>>> the >>>> 6.12.* versions. >>>> >>>> This may be a good reason for the more memory-hungry BOINC projects >>>> to start offering 64-bit applications, even if those 64-bit versions >>>> offer no performance improvements over the 32-bit versions. _______________________________________________ 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.
