Vincent Stemen wrote:
> The problem is, that's not true. These problems are not slipping
> through because of lack of testers.
Just to add some sanity to this thread, I have been using the 2.4.x
kernels ever since they came out, on my personal workstation and on some
workstations
On Wed, 30 May 2001, Vincent Stemen wrote:
> On Wednesday 30 May 2001 15:17, Mike Galbraith wrote:
> > On Wed, 30 May 2001, Vincent Stemen wrote:
> > > On Wednesday 30 May 2001 01:02, Mike Galbraith wrote:
> > > > On Tue, 29 May 2001, Vincent Stemen wrote:
> > > > > On Tuesday 29 May 2001 15:16,
On Wed, 30 May 2001, Marcelo Tosatti wrote:
> On Wed, 30 May 2001, Mike Galbraith wrote:
>
> > On Wed, 30 May 2001, Rik van Riel wrote:
> >
> > > On Wed, 30 May 2001, Marcelo Tosatti wrote:
> > >
> > > > The problem is that we allow _every_ task to age pages on the system
> > > > at the same
On Wednesday 30 May 2001 15:17, Mike Galbraith wrote:
> On Wed, 30 May 2001, Vincent Stemen wrote:
> > On Wednesday 30 May 2001 01:02, Mike Galbraith wrote:
> > > On Tue, 29 May 2001, Vincent Stemen wrote:
> > > > On Tuesday 29 May 2001 15:16, Alan Cox wrote:
> > > > > > a reasonably stable
On Wednesday 30 May 2001 15:30, Rik van Riel wrote:
> On Wed, 30 May 2001, Vincent Stemen wrote:
> > The problem is, that's not true. These problems are not slipping
> > through because of lack of testers. As Alan said, the VM problem has
> > been lurking, which means that it was known already.
Ronald Bultje writes:
> On 30 May 2001 14:58:57 -0500, Vincent Stemen wrote:
> > There was a new 8139too driver added to the the 2.4.5 (I think) kernel
> > which Alan Cox took back out and reverted to the old one in his
> > 2.4.5-ac? versions because it is apparently causing lockups.
> >
On Wed, 30 May 2001, Mike Galbraith wrote:
> On Wed, 30 May 2001, Rik van Riel wrote:
>
> > On Wed, 30 May 2001, Marcelo Tosatti wrote:
> >
> > > The problem is that we allow _every_ task to age pages on the system
> > > at the same time --- this is one of the things which is fucking up.
> >
On Wed, 30 May 2001, Rik van Riel wrote:
> On Wed, 30 May 2001, Marcelo Tosatti wrote:
>
> > The problem is that we allow _every_ task to age pages on the system
> > at the same time --- this is one of the things which is fucking up.
>
> This should not have any effect on the ratio of cache
>
On Wed, 30 May 2001, Vincent Stemen wrote:
> The problem is, that's not true. These problems are not slipping
> through because of lack of testers. As Alan said, the VM problem has
> been lurking, which means that it was known already.
Fully agreed, it went through because of a lack of hours
> There was a new 8139too driver added to the the 2.4.5 (I think) kernel
> which Alan Cox took back out and reverted to the old one in his
> 2.4.5-ac? versions because it is apparently causing lockups.
> Shouldn't this new driver have been released in a 2.5.x development
> kernel and proven there
On Wednesday 30 May 2001 01:02, Mike Galbraith wrote:
> On Tue, 29 May 2001, Vincent Stemen wrote:
> > On Tuesday 29 May 2001 15:16, Alan Cox wrote:
> > > > a reasonably stable release until 2.2.12. I do not understand why
> > > > code with such serious reproducible problems is being introduced
On Wed, 30 May 2001, Mike Galbraith wrote:
> I wouldn't go so far as to say totally broken (mostly because I've
> tried like _hell_ to find a better way, and [despite minor successes]
> I've not been able to come up with something which covers all cases
> that even _I_ [hw tech] can think of
On Wed, 30 May 2001, Rik van Riel wrote:
> On Wed, 30 May 2001, Marcelo Tosatti wrote:
>
> > The problem is that we allow _every_ task to age pages on the system
> > at the same time --- this is one of the things which is fucking up.
>
> This should not have any effect on the ratio of cache
>
On Wed, 30 May 2001, Marcelo Tosatti wrote:
> The problem is that we allow _every_ task to age pages on the system
> at the same time --- this is one of the things which is fucking up.
This should not have any effect on the ratio of cache
reclaiming vs. swapout use, though...
> The another
On Wed, 30 May 2001, Marcelo Tosatti wrote:
> On Wed, 30 May 2001, Jonathan Morton wrote:
>
> > >The page aging logic does seems fragile as heck. You never know how
> > >many folks are aging pages or at what rate. If aging happens too fast,
> > >it defeats the garbage identification logic and
On Wed, 30 May 2001, Jonathan Morton wrote:
> >The page aging logic does seems fragile as heck. You never know how
> >many folks are aging pages or at what rate. If aging happens too fast,
> >it defeats the garbage identification logic and you rape your cache. If
> >aging happens too
On Wed, 30 May 2001, Jonathan Morton wrote:
> >The page aging logic does seems fragile as heck. You never know how
> >many folks are aging pages or at what rate. If aging happens too fast,
> >it defeats the garbage identification logic and you rape your cache. If
> >aging happens too
>The page aging logic does seems fragile as heck. You never know how
>many folks are aging pages or at what rate. If aging happens too fast,
>it defeats the garbage identification logic and you rape your cache. If
>aging happens too slowly.. sigh.
Then it sounds like the current algorithm
On Tue, 29 May 2001, Craig Kulesa wrote:
> Mike Galbraith ([EMAIL PROTECTED]) wrote:
> >
> > Emphatic yes. We went from cache collapse to cache bloat.
>
> Rik, I think Mike deserves his beer. ;)
:)
...
> So is there an ideal VM balance for everyone? I have found that low-RAM
(I seriously
On Tue, 29 May 2001, Craig Kulesa wrote:
Mike Galbraith ([EMAIL PROTECTED]) wrote:
Emphatic yes. We went from cache collapse to cache bloat.
Rik, I think Mike deserves his beer. ;)
:)
...
So is there an ideal VM balance for everyone? I have found that low-RAM
(I seriously doubt
On Wed, 30 May 2001, Jonathan Morton wrote:
The page aging logic does seems fragile as heck. You never know how
many folks are aging pages or at what rate. If aging happens too fast,
it defeats the garbage identification logic and you rape your cache. If
aging happens too slowly..
On Wed, 30 May 2001, Jonathan Morton wrote:
The page aging logic does seems fragile as heck. You never know how
many folks are aging pages or at what rate. If aging happens too fast,
it defeats the garbage identification logic and you rape your cache. If
aging happens too slowly..
On Wed, 30 May 2001, Marcelo Tosatti wrote:
On Wed, 30 May 2001, Jonathan Morton wrote:
The page aging logic does seems fragile as heck. You never know how
many folks are aging pages or at what rate. If aging happens too fast,
it defeats the garbage identification logic and you rape
On Wed, 30 May 2001, Marcelo Tosatti wrote:
The problem is that we allow _every_ task to age pages on the system
at the same time --- this is one of the things which is fucking up.
This should not have any effect on the ratio of cache
reclaiming vs. swapout use, though...
The another
On Wed, 30 May 2001, Rik van Riel wrote:
On Wed, 30 May 2001, Marcelo Tosatti wrote:
The problem is that we allow _every_ task to age pages on the system
at the same time --- this is one of the things which is fucking up.
This should not have any effect on the ratio of cache
On Wed, 30 May 2001, Mike Galbraith wrote:
I wouldn't go so far as to say totally broken (mostly because I've
tried like _hell_ to find a better way, and [despite minor successes]
I've not been able to come up with something which covers all cases
that even _I_ [hw tech] can think of well).
On Wed, 30 May 2001, Rik van Riel wrote:
On Wed, 30 May 2001, Marcelo Tosatti wrote:
The problem is that we allow _every_ task to age pages on the system
at the same time --- this is one of the things which is fucking up.
This should not have any effect on the ratio of cache
reclaiming
On Wed, 30 May 2001, Mike Galbraith wrote:
On Wed, 30 May 2001, Rik van Riel wrote:
On Wed, 30 May 2001, Marcelo Tosatti wrote:
The problem is that we allow _every_ task to age pages on the system
at the same time --- this is one of the things which is fucking up.
This should
Ronald Bultje writes:
On 30 May 2001 14:58:57 -0500, Vincent Stemen wrote:
There was a new 8139too driver added to the the 2.4.5 (I think) kernel
which Alan Cox took back out and reverted to the old one in his
2.4.5-ac? versions because it is apparently causing lockups.
Shouldn't
On Wednesday 30 May 2001 15:30, Rik van Riel wrote:
On Wed, 30 May 2001, Vincent Stemen wrote:
The problem is, that's not true. These problems are not slipping
through because of lack of testers. As Alan said, the VM problem has
been lurking, which means that it was known already.
On Wed, 30 May 2001, Marcelo Tosatti wrote:
On Wed, 30 May 2001, Mike Galbraith wrote:
On Wed, 30 May 2001, Rik van Riel wrote:
On Wed, 30 May 2001, Marcelo Tosatti wrote:
The problem is that we allow _every_ task to age pages on the system
at the same time --- this is one of
On Wednesday 30 May 2001 15:17, Mike Galbraith wrote:
On Wed, 30 May 2001, Vincent Stemen wrote:
On Wednesday 30 May 2001 01:02, Mike Galbraith wrote:
On Tue, 29 May 2001, Vincent Stemen wrote:
On Tuesday 29 May 2001 15:16, Alan Cox wrote:
a reasonably stable release until 2.2.12.
On Wed, 30 May 2001, Vincent Stemen wrote:
The problem is, that's not true. These problems are not slipping
through because of lack of testers. As Alan said, the VM problem has
been lurking, which means that it was known already.
Fully agreed, it went through because of a lack of hours
per
On Wed, 30 May 2001, Vincent Stemen wrote:
On Wednesday 30 May 2001 15:17, Mike Galbraith wrote:
On Wed, 30 May 2001, Vincent Stemen wrote:
On Wednesday 30 May 2001 01:02, Mike Galbraith wrote:
On Tue, 29 May 2001, Vincent Stemen wrote:
On Tuesday 29 May 2001 15:16, Alan Cox
On Wednesday 30 May 2001 01:02, Mike Galbraith wrote:
On Tue, 29 May 2001, Vincent Stemen wrote:
On Tuesday 29 May 2001 15:16, Alan Cox wrote:
a reasonably stable release until 2.2.12. I do not understand why
code with such serious reproducible problems is being introduced
into
There was a new 8139too driver added to the the 2.4.5 (I think) kernel
which Alan Cox took back out and reverted to the old one in his
2.4.5-ac? versions because it is apparently causing lockups.
Shouldn't this new driver have been released in a 2.5.x development
kernel and proven there
On Tue, 29 May 2001, Vincent Stemen wrote:
> On Tuesday 29 May 2001 15:16, Alan Cox wrote:
> > > a reasonably stable release until 2.2.12. I do not understand why
> > > code with such serious reproducible problems is being introduced into
> > > the even numbered kernels. What happened to the
Mike Galbraith ([EMAIL PROTECTED]) wrote:
>
> Emphatic yes. We went from cache collapse to cache bloat.
Rik, I think Mike deserves his beer. ;)
Agreed. Swap reclaim doesn't seem to be the root issue here, IMHO.
But instead: his box was capable of maintaining a modest cache
and the desired
> a reasonably stable release until 2.2.12. I do not understand why
> code with such serious reproducible problems is being introduced into
> the even numbered kernels. What happened to the plan to use only the
Who said it was introduced ?? It was more 'lurking' than introduced. And
On Tuesday 29 May 2001 10:37, elko wrote:
> On Tuesday 29 May 2001 11:10, Alan Cox wrote:
> > > It's not a bug. It's a feature. It only breaks systems that are run
> > > w= ith "too
> > > little" swap, and the only difference from 2.2 till now is, that the
> > > de= finition
> > > of "too
On Tuesday 29 May 2001 11:10, Alan Cox wrote:
> > It's not a bug. It's a feature. It only breaks systems that are run w=
> > ith "too
> > little" swap, and the only difference from 2.2 till now is, that the de=
> > finition
> > of "too little" changed.
>
> its a giant bug. Or do you want to add
> It's not a bug. It's a feature. It only breaks systems that are run w=
> ith "too
> little" swap, and the only difference from 2.2 till now is, that the de=
> finition
> of "too little" changed.
its a giant bug. Or do you want to add 128Gb of unused swap to a full kitted
out Xeon box - or
> Ouch! When compiling MySql, building sql_yacc.cc results in a ~300M
> cc1plus process size. Unfortunately this leads the machine with 380M of
> RAM deeply into swap:
>
> Mem: 381608K av, 248504K used, 133104K free, 0K shrd, 192K
> buff
> Swap: 255608K av, 255608K used,
On Tuesday 29 May 2001 11:10, Alan Cox wrote:
It's not a bug. It's a feature. It only breaks systems that are run w=
ith too
little swap, and the only difference from 2.2 till now is, that the de=
finition
of too little changed.
its a giant bug. Or do you want to add 128Gb of unused
On Tuesday 29 May 2001 10:37, elko wrote:
On Tuesday 29 May 2001 11:10, Alan Cox wrote:
It's not a bug. It's a feature. It only breaks systems that are run
w= ith too
little swap, and the only difference from 2.2 till now is, that the
de= finition
of too little changed.
its
Mike Galbraith ([EMAIL PROTECTED]) wrote:
Emphatic yes. We went from cache collapse to cache bloat.
Rik, I think Mike deserves his beer. ;)
Agreed. Swap reclaim doesn't seem to be the root issue here, IMHO.
But instead: his box was capable of maintaining a modest cache
and the desired
Ouch! When compiling MySql, building sql_yacc.cc results in a ~300M
cc1plus process size. Unfortunately this leads the machine with 380M of
RAM deeply into swap:
Mem: 381608K av, 248504K used, 133104K free, 0K shrd, 192K
buff
Swap: 255608K av, 255608K used, 0K free
a reasonably stable release until 2.2.12. I do not understand why
code with such serious reproducible problems is being introduced into
the even numbered kernels. What happened to the plan to use only the
Who said it was introduced ?? It was more 'lurking' than introduced. And
It's not a bug. It's a feature. It only breaks systems that are run w=
ith too
little swap, and the only difference from 2.2 till now is, that the de=
finition
of too little changed.
its a giant bug. Or do you want to add 128Gb of unused swap to a full kitted
out Xeon box - or 512Gb to a
On Tue, 29 May 2001, Vincent Stemen wrote:
On Tuesday 29 May 2001 15:16, Alan Cox wrote:
a reasonably stable release until 2.2.12. I do not understand why
code with such serious reproducible problems is being introduced into
the even numbered kernels. What happened to the plan to use
On Tue, 29 May 2001, Jeff Garzik wrote:
> > On Tuesday 29 May 2001 00:10, Jakob Østergaard wrote:
> >
> > > > > Mem: 381608K av, 248504K used, 133104K free, 0K shrd, 192K
> > > > > buff
> > > > > Swap: 255608K av, 255608K used, 0K free 215744K
> > > > > cached
> > > > >
> > > > > Vanilla 2.4.5
> On Tuesday 29 May 2001 00:10, Jakob Østergaard wrote:
>
> > > > Mem: 381608K av, 248504K used, 133104K free, 0K shrd, 192K
> > > > buff
> > > > Swap: 255608K av, 255608K used, 0K free 215744K
> > > > cached
> > > >
> > > > Vanilla 2.4.5 VM.
>
> > It's not a bug. It's a feature. It only
On Tue, May 29, 2001 at 01:46:28PM +0900, G. Hugh Song wrote:
> Jakob,
>
> My Alpha has 2GB of physical memory. In this case how much swap space
> should
> I assign in these days of kernel 2.4.*? I had had trouble with 1GB of
> swap space
> before switching back to 2.2.20pre2aa1.
If you run a
Jakob,
My Alpha has 2GB of physical memory. In this case how much swap space
should
I assign in these days of kernel 2.4.*? I had had trouble with 1GB of
swap space
before switching back to 2.2.20pre2aa1.
Thanks
--
G. Hugh Song
-
To unsubscribe from this list: send the line "unsubscribe
On Tue, May 29, 2001 at 11:32:09AM +0900, G. Hugh Song wrote:
>
> Jeff Garzik wrote:
> >
> > Ouch! When compiling MySql, building sql_yacc.cc results in a ~300M
> > cc1plus process size. Unfortunately this leads the machine with 380M of
> > RAM deeply into swap:
> >
> > Mem: 381608K av,
Jeff Garzik wrote:
>
> Ouch! When compiling MySql, building sql_yacc.cc results in a ~300M
> cc1plus process size. Unfortunately this leads the machine with 380M of
> RAM deeply into swap:
>
> Mem: 381608K av, 248504K used, 133104K free, 0K shrd, 192K
> buff
> Swap: 255608K av, 255608K
Jeff Garzik wrote:
>
> Ouch! When compiling MySql, building sql_yacc.cc results in a ~300M
> cc1plus process size. Unfortunately this leads the machine with 380M of
> RAM deeply into swap:
>
> Mem: 381608K av, 248504K used, 133104K free, 0K shrd, 192K
> buff
> Swap: 255608K av,
Jeff Garzik wrote:
Ouch! When compiling MySql, building sql_yacc.cc results in a ~300M
cc1plus process size. Unfortunately this leads the machine with 380M of
RAM deeply into swap:
Mem: 381608K av, 248504K used, 133104K free, 0K shrd, 192K
buff
Swap: 255608K av,
Jeff Garzik wrote:
Ouch! When compiling MySql, building sql_yacc.cc results in a ~300M
cc1plus process size. Unfortunately this leads the machine with 380M of
RAM deeply into swap:
Mem: 381608K av, 248504K used, 133104K free, 0K shrd, 192K
buff
Swap: 255608K av, 255608K used, 0K
On Tue, May 29, 2001 at 11:32:09AM +0900, G. Hugh Song wrote:
Jeff Garzik wrote:
Ouch! When compiling MySql, building sql_yacc.cc results in a ~300M
cc1plus process size. Unfortunately this leads the machine with 380M of
RAM deeply into swap:
Mem: 381608K av, 248504K used,
Jakob,
My Alpha has 2GB of physical memory. In this case how much swap space
should
I assign in these days of kernel 2.4.*? I had had trouble with 1GB of
swap space
before switching back to 2.2.20pre2aa1.
Thanks
--
G. Hugh Song
-
To unsubscribe from this list: send the line unsubscribe
On Tue, May 29, 2001 at 01:46:28PM +0900, G. Hugh Song wrote:
Jakob,
My Alpha has 2GB of physical memory. In this case how much swap space
should
I assign in these days of kernel 2.4.*? I had had trouble with 1GB of
swap space
before switching back to 2.2.20pre2aa1.
If you run a single
On Tuesday 29 May 2001 00:10, Jakob Østergaard wrote:
Mem: 381608K av, 248504K used, 133104K free, 0K shrd, 192K
buff
Swap: 255608K av, 255608K used, 0K free 215744K
cached
Vanilla 2.4.5 VM.
It's not a bug. It's a feature. It only breaks systems that are run with
On Tue, 29 May 2001, Jeff Garzik wrote:
On Tuesday 29 May 2001 00:10, Jakob Østergaard wrote:
Mem: 381608K av, 248504K used, 133104K free, 0K shrd, 192K
buff
Swap: 255608K av, 255608K used, 0K free 215744K
cached
Vanilla 2.4.5 VM.
It's not a bug. It's a
64 matches
Mail list logo
