Here is a message from Steve Kieu that he couldn't get through...
--
Einstein did not prove that everything is relative.
Einstein explained how the speed of light could be constant.
Benjamin Redelings I <>< http://www.bol.ucla.edu/~bredelin/
Just add my experience here...
I use up t
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 that
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 time
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 releas
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.
> > Shou
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
> rec
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
p
> 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 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
>
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 prob
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 y
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..
>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 i
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 d
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 pl
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 u
> 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
unfortunat
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
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
> * when you have an active process using ~300M of VM, in a ~380M machine,
> 2/3 of the machine's RAM should -not- be soaked up by cache
>
> * when you have an active process using ~300M of VM, in a ~380M machine,
> swap should not be full while there is 133M of RAM available.
>
> The above quot
> 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 512
On Tue, 29 May 2001, Jakob Østergaard wrote:
>
> It's not a bug. It's a feature. It only breaks systems that are run with "too
> little" swap, and the only difference from 2.2 till now is, that the definition
> of "too little" changed.
Its just a balancing change, actually. You can tune the
> 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, 0
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
> 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 break
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 linu
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 r
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, 248
> 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
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 us
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,
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
40 matches
Mail list logo
