Re: Detecting ulimit problem

[Daniel Kegel]

[e-mail] 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 :-)

Detecting ulimit problem

[Eric Frias]

Daniel Kegel wrote:
> [e-mail] 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

Detecting ulimit problem

[Mike Hearn]

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

Detecting ulimit problem

[Eric Frias]

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

Detecting ulimit problem

[Robert Lunnon]

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

Detecting ulimit problem

[Alexandre Julliard]

Robert Lunnon  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.