efrias(a)syncad.com wrote:
http://bugs.winehq.org/show_bug.cgi?id=2609 [Proposed fix:] struct rlimit address_limits; int required_address_space = 1024 * 1024 * 1400; /* 1400M */ getrlimit(RLIMIT_AS, &address_limits); if (address_limits.rlim_max < required_address_space) WINE_WARN("Your virtual memory limit is set to %dk, which will\nprobably prevent wine from loading correctly. If you get an error,\nincrease the limit with 'ulimit -v' to at least %dk.\n", address_limits.rlim_max / 1024, required_address_space / 1024);
Looks groovy to me. But it will completely annoy people using 2.4 kernels, which by default have only 896MB of user address space, won't it? (I may be confused here, but that's what I remember.) See e.g. http://mail.nl.linux.org/kernelnewbies/2004-12/msg00073.html + On a system with 1 gigabyte of memory, you may get 896 MB of + "user memory" and 128 megabytes of "high memory" with this + selection. This is the usual setting. So I'd encourage you to submit a patch to do this, but only after testing on Red Hat 9.0 to make sure I'm wrong :-)
Daniel Kegel wrote:
efrias(a)syncad.com wrote:
http://bugs.winehq.org/show_bug.cgi?id=2609 [Proposed fix:] struct rlimit address_limits; int required_address_space = 1024 * 1024 * 1400; /* 1400M */ getrlimit(RLIMIT_AS, &address_limits); if (address_limits.rlim_max < required_address_space) WINE_WARN("Your virtual memory limit is set to %dk, which will\nprobably prevent wine from loading correctly. If you get an error,\nincrease the limit with 'ulimit -v' to at least %dk.\n", address_limits.rlim_max / 1024, required_address_space / 1024);
Looks groovy to me. But it will completely annoy people using 2.4 kernels, which by default have only 896MB of user address space, won't it? (I may be confused here, but that's what I remember.)
Hm... I hadn't heard of this. But I have to admit, I don't have a very good grasp of what is going on in wine that causes it to need over a gig of address space. I think this patch is safe, since it just reports the user-imposed limits, and not what the system actually makes available. To make sure, I just tested on RedHat 7.2, 8, 9, and Fedora Core 3, and they all have the same behavior: they return the limit you've set with 'ulimit -v', or -1 (RLIM_INFINITY) if no limit has been set. That covers the 2.4 and 2.6 series kernels. So I guess my test above was incorrect -- it should have been: if (address_limits.rlim_max != RLIM_INFINITY && address_limits.rlim_max < required_address_space)
So I'd encourage you to submit a patch to do this, but only after testing on Red Hat 9.0 to make sure I'm wrong :-)
I'll get a patch ready once I understand a bit more of what is going on that is causing wine to reserve this memory. I'd love to figure out how to get rid of the hard-coded constant, because it looks like it's not going to be big enough for some apps, but it'll be too large for others. It's probably still better than nothing, but I'd rather do it right if that's possible. Eric
On Thu, 19 May 2005 17:46:28 -0400, Eric Frias wrote:
I'll get a patch ready once I understand a bit more of what is going on that is causing wine to reserve this memory.
It's probably blocking off the top 3rd quarter of the address space to prevent the kernel allocating memory above the 2gig boundary (this can break some Windows programs). It wouldn't be necessary if the kernel had the new mmap call Alexandre wanted. But for now it is. thanks -mike
Mike Hearn wrote:
On Thu, 19 May 2005 17:46:28 -0400, Eric Frias wrote:
I'll get a patch ready once I understand a bit more of what is going on that is causing wine to reserve this memory. It's probably blocking off the top 3rd quarter of the address space to prevent the kernel allocating memory above the 2gig boundary (this can break some Windows programs).
Thanks for the explanation. I just read over that section in the developer's guide, and it's starting to make sense. Sounds like it won't be straightforward to figure out *exactly* how much memory wine is going to require, because it should amount to roughly: whatever the preloader reserves in the low addresses + the size of native linux libraries not mapped in the 3rd gig + heap used by native libraries (?) + 1G to block off that 3rd quarter So the requirements of 1300 megabytes I was seeing dosn't seem that unrealistic. I couldn't tell from the docs, but it sounds likely that wine would also reserve the 4th quarter of the address space if the 4G VM split patch was in effect, so wine would actually need around 2300 megabytes of address space on those systems. Eric
On Sat, 21 May 2005 04:40 am, Eric Frias wrote:
Mike Hearn wrote:
On Thu, 19 May 2005 17:46:28 -0400, Eric Frias wrote:
I'll get a patch ready once I understand a bit more of what is going on that is causing wine to reserve this memory.
It's probably blocking off the top 3rd quarter of the address space to prevent the kernel allocating memory above the 2gig boundary (this can break some Windows programs).
Thanks for the explanation. I just read over that section in the developer's guide, and it's starting to make sense. Sounds like it won't be straightforward to figure out *exactly* how much memory wine is going to require, because it should amount to roughly:
whatever the preloader reserves in the low addresses + the size of native linux libraries not mapped in the 3rd gig + heap used by native libraries (?) + 1G to block off that 3rd quarter
So the requirements of 1300 megabytes I was seeing dosn't seem that unrealistic. I couldn't tell from the docs, but it sounds likely that wine would also reserve the 4th quarter of the address space if the 4G VM split patch was in effect, so wine would actually need around 2300 megabytes of address space on those systems.
Eric
Really we need a better way. Under Solaris I have run into these problems for well over 2 years and I have a patch in my kit that pre-allocates 64MB for the heap then lets mmap allocate over the 2 GB limit for everything else, eg DLLs and so on. This seems to work pretty well, but it's been rejected as a fix to wine. Bob
Robert Lunnon <bobl(a)optushome.com.au> writes:
Really we need a better way. Under Solaris I have run into these problems for well over 2 years and I have a patch in my kit that pre-allocates 64MB for the heap then lets mmap allocate over the 2 GB limit for everything else, eg DLLs and so on. This seems to work pretty well, but it's been rejected as a fix to wine.
It doesn't solve the issue anyway, the problem is not so much heap addresses (which is trivial to fix), it's the dll addresses, they have to all be under the 2Gb mark, including builtins. -- Alexandre Julliard julliard(a)winehq.org
participants (5)
-
Alexandre Julliard -
Daniel Kegel -
Eric Frias -
Mike Hearn -
Robert Lunnon