On Sun, 8 Oct 2000, Linus Torvalds wrote:
> On Wed, 4 Oct 2000, Rik van Riel wrote:
> >
> > The potential for this bug has been around since 2.3.51, when
> > different balance_ratios for different zones became possible.
> You must NOT depend on some global "freepages" thing.
> Don't do this pat
On Sun, Oct 08, 2000 at 08:27:24AM -0700, Linus Torvalds wrote:
> Why? Think NUMA. The global freepages number is NOT USABLE. Never will be.
> Because it's fundamentally a non-valid number to use - it has nothing to
> do with any reality, and never will.
>
> This is exactly my argument and beef w
On Wed, 4 Oct 2000, Rik van Riel wrote:
>
> The potential for this bug has been around since 2.3.51, when
> different balance_ratios for different zones became possible.
No, the bug has been around since your VM.
You must NOT depend on some global "freepages" thing.
You MUST do your freepage
Ok, those two patches (well, I applied both, so I can't decide which was
the triggering factor) makes the system able to deplete the swap before
hanging. Thus, things are fine, right?!
I just hope that we can get a decent OOM-killer now.
Two other considerations, which I remember have been disc
Rik van Riel wrote:
>
> On Wed, 4 Oct 2000, Roger Larsson wrote:
> > Rik van Riel wrote:
> > > On Wed, 4 Oct 2000, Rik van Riel wrote:
> > >
> > > > > > First, you have MORE free memory than freepages.high. In this
> > > > > > case I really don't see why __alloc_pages() wouldn't give the
> > > >
On Wed, 4 Oct 2000, Roger Larsson wrote:
> Rik van Riel wrote:
> > On Wed, 4 Oct 2000, Rik van Riel wrote:
> >
> > > > > First, you have MORE free memory than freepages.high. In this
> > > > > case I really don't see why __alloc_pages() wouldn't give the
> > > > > memory to your processes
>
Rik van Riel wrote:
>
> On Wed, 4 Oct 2000, Rik van Riel wrote:
>
> > > > First, you have MORE free memory than freepages.high. In this
> > > > case I really don't see why __alloc_pages() wouldn't give the
> > > > memory to your processes
> > >
> > > Hmm...
> > > Can't it be a zone problem?
On Wed, 4 Oct 2000, Rik van Riel wrote:
> > > First, you have MORE free memory than freepages.high. In this
> > > case I really don't see why __alloc_pages() wouldn't give the
> > > memory to your processes
> >
> > Hmm...
> > Can't it be a zone problem?
> > Free pages is the total free - al
On Wed, 4 Oct 2000, Roger Larsson wrote:
> Rik van Riel wrote:
> > On Wed, 4 Oct 2000, David Weinehall wrote:
> >
> > > Running the included program on a clean v2.4.0test9 kernel I can
> > > hang the computer practically in no time.
> >
> > > What seems most strange is that the doesn't even get
Rik van Riel wrote:
>
> On Wed, 4 Oct 2000, David Weinehall wrote:
>
> > Running the included program on a clean v2.4.0test9 kernel I can
> > hang the computer practically in no time.
>
> > What seems most strange is that the doesn't even get depleated.
> > The machine still answers to SysRq an
]
To: David Weinehall <[EMAIL PROTECTED]>
cc: [EMAIL PROTECTED], Linus Torvalds <[EMAIL PROTECTED]>
Subject: Re: VM in v2.4.0test9
On Wed, 4 Oct 2000, David Weinehall wrote:
> Running the included program on a clean v2.4.0test9 kernel I can
> hang the computer practically i
On Wed, Oct 04, 2000 at 01:01:21PM -0300, Rik van Riel wrote:
> On Wed, 4 Oct 2000, David Weinehall wrote:
>
> > Running the included program on a clean v2.4.0test9 kernel I can
> > hang the computer practically in no time.
>
> > What seems most strange is that the doesn't even get depleated.
>
On Wed, 4 Oct 2000, David Weinehall wrote:
> Running the included program on a clean v2.4.0test9 kernel I can
> hang the computer practically in no time.
> What seems most strange is that the doesn't even get depleated.
> The machine still answers to SysRq and ping, but nothing else.
Looking ag
On Wed, 4 Oct 2000, David Weinehall wrote:
> On Wed, Oct 04, 2000 at 12:31:13PM -0300, Rik van Riel wrote:
> > On Wed, 4 Oct 2000, David Weinehall wrote:
> >
> > > Running the included program on a clean v2.4.0test9 kernel I can
> > > hang the computer practically in no time. The only other
> >
On Wed, 4 Oct 2000, Chris Evans wrote:
> On Wed, 4 Oct 2000, Rik van Riel wrote:
>
> > Handling out-of-memory in a clean and predictable way is the
> > next thing on the feature list. I'll add it RSN (I'm reasonably
> > sure now that the current VM features are stable ... time for
> > OOM handlin
On Wed, 4 Oct 2000, Rik van Riel wrote:
> Handling out-of-memory in a clean and predictable way is the
> next thing on the feature list. I'll add it RSN (I'm reasonably
> sure now that the current VM features are stable ... time for
> OOM handling).
Stable is good. But before moving on, wouldn'
On Wed, Oct 04, 2000 at 12:31:13PM -0300, Rik van Riel wrote:
> On Wed, 4 Oct 2000, David Weinehall wrote:
>
> > Running the included program on a clean v2.4.0test9 kernel I can
> > hang the computer practically in no time. The only other
>
> [OUT OF MEMORY PROGRAM]
>
> > runnning process
On Wed, 4 Oct 2000, David Weinehall wrote:
> Running the included program on a clean v2.4.0test9 kernel I can
> hang the computer practically in no time. The only other
[OUT OF MEMORY PROGRAM]
> runnning process that can be of interest is dnetc. Running the
> same on a v2.2.xx kernel wi
Running the included program on a clean v2.4.0test9 kernel I can hang
the computer practically in no time. The only other runnning process
that can be of interest is dnetc. Running the same on a v2.2.xx kernel
will just depleat the memory then kill the offending process, leaving
everything nice an
19 matches
Mail list logo
