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 > > > End of boinc_dev Digest, Vol 95, Issue 23 > ***************************************** > _______________________________________________ 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.
