> On Tue, Sep 18, 2001 at 12:55:46AM -0300, Marcelo Tosatti wrote:
> >
> >
> > On Tue, 18 Sep 2001, Andrea Arcangeli wrote:
> >
> > > On Tue, Sep 18, 2001 at 12:33:15AM -0300, Marcelo Tosatti wrote:
> > > >
> > > > On Tue, 18 Sep 2001, Andrea Arcangeli wrote:
> > > >
> > > > > On Mon, Sep 17, 2001 at 11:53:10PM -0300, Marcelo Tosatti wrote:
> > > > > > Don't you agree that your code can introduce new stability bugs ?
> > > > >
> > > > > not anything that can corrupt randomly your hd.
> > > >
> > > > Sure, the old code did not corrupt hd's randomly, did it?
> > > >
> > > > Let me redo the question: Don't you think the old stinky and slow code was
> > > > reasonably stable ? :)
> > >
> > > As said in the other email, just check 2.4 l-k reports of this week,
> > > last week etc.., I've lots of private reports too. While for everybody
> > > 2.2.19 is working fine.
> >
> > Have you seen any problem report which does not happen with anon intensive
> > workloads ?
>
> of course, all the mysql/postgres db reports I got were non anon
> intensive I assume, I assume they had enough ram, they all said 2.2 was
> fine.
>
> > As far as I've noted, people usually report performance problems when
> > running anon intensive workloads. For those cases, I'm pretty sure the
> > swap_out() loop is the fuckup: the swap allocation code is really a _CRAP_
> > for the current VM.
>
> I don't think that was the case, 2.2 has the same swap_out loop.
Ok, back to the current allocation failure problem.
In addition to the zone specific page hiding problem, I'm afraid threads
can hide pages from themselves up to a point there is nothing to block on
(even if we have just one zone).
There is nothing which avoids that from happening in theory.
Well, I'm going to sleep now.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/