Re: Linux 2.4.10-pre11

Marcelo Tosatti
2001-09-18T06:24:32Z

On Tue, 18 Sep 2001, Andrea Arcangeli wrote:

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