> That probably would mean that all the software should switch to a new
> way of allocating memory, but it's a start...
...its only "a start" if you consider the current behaviour to be a problem.
which under most normal uses of FreeBSd (and all the other UNIXs which
do this) it doesnt seem to be.
On Thu, 24 Jul 2003 19:18:06 -0400 Chuck Swiger <[EMAIL PROTECTED]> wrote:
> Muttley wrote:
> > Yes, I thought briefly about something like this.
> >
> > Then I thought 'there's a race condition'.
>
> Where? The FreeBSD implementation is wrapped in a THREAD_LOCK()...?
Good point, well made
>
On 24 Jul, Pete French punched keys in this particular order:
> Its not bogus - the trouble is that you cant tell at the time malloc returns
> whether the pointer will be useable or not. You only find that out when
> you try and use it, and whether theres any space or not depends oon what
> else ma
On Wed, Jul 23, 2003 at 11:44:11PM -0400, Mike Tancsa wrote:
> At 08:15 PM 7/23/2003 -0700, Kris Kennaway wrote:
> >On Wed, Jul 23, 2003 at 01:34:27PM -0400, Gabor wrote:
> >
> >> Here is the tail end of the output. It dies when trying to poke at
> >> the memory using memset. If I just malloc wit
Mike Tancsa wrote:
At 08:15 PM 7/23/2003 -0700, Kris Kennaway wrote:
On Wed, Jul 23, 2003 at 01:34:27PM -0400, Gabor wrote:
> Here is the tail end of the output. It dies when trying to poke at
> the memory using memset. If I just malloc without the memset, it
> never even dies.
Ah, the annual
At 08:15 PM 7/23/2003 -0700, Kris Kennaway wrote:
On Wed, Jul 23, 2003 at 01:34:27PM -0400, Gabor wrote:
> Here is the tail end of the output. It dies when trying to poke at
> the memory using memset. If I just malloc without the memset, it
> never even dies.
Ah, the annual "memory overcommit" t
On Wed, Jul 23, 2003 at 01:34:27PM -0400, Gabor wrote:
> Here is the tail end of the output. It dies when trying to poke at
> the memory using memset. If I just malloc without the memset, it
> never even dies.
Ah, the annual "memory overcommit" thread. I thought we were overdue
for one.
Kris
Peter Jeremy wrote:
FreeBSD behaviour in the face of swap shortage is a regular and
popular discussion topic. I suggest that a perusal of the archives
Yes but I for example have had this issue since 2.1-R (when I started
using it), freezing when the system trashes, without hope for resolve,
or
Peter Jeremy wrote:
FreeBSD behaviour in the face of swap shortage is a regular and
popular discussion topic. I suggest that a perusal of the archives
will probably answer any questions. If anyone wishes to suggest a
"solution" to FreeBSD's behaviour when there is a shortage of swap,
please incl
On 2003-Jul-23 15:44:36 -0700, Brooks Davis <[EMAIL PROTECTED]> wrote:
>On Thu, Jul 24, 2003 at 12:36:54AM +0200, Matthias Buelow wrote:
>> Wasn't there a sysctl flag to enable/disable overcommitting?
>> I think I remember something but I can't find it; it might
>> not have been on FreeBSD.
>
>No t
On 23 Jul, Brooks Davis wrote:
> On Thu, Jul 24, 2003 at 12:36:54AM +0200, Matthias Buelow wrote:
>> Barney Wolff writes:
>>
>> >One might argue that this is a config error, and ulimit should be used
>> >to cut the address space to below actually available memory.
>>
>> Wasn't there a sysctl flag
11 matches
Mail list logo
