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. _______________________________________________ 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.
