> On a side question: does Linux support swap-files in addition to
> sawp-partitions? Even if that has a performance penalty, when the system
> is swapping performance is dead anyway.
Yes.
A possible solution could be:
> dd if=/dev/zero of=/swap bs=1M count=
> mkswap /swap
> swapon /swap
Work
> On a side question: does Linux support swap-files in addition to
>sawp-partitions? Even if that has a performance penalty, when the system
>is swapping performance is dead anyway.
Yes. Simply use mkswap and swapon/off on a regular file instead of a
partition device. I don't notice any signifi
> On a side question: does Linux support swap-files in addition to
> sawp-partitions? Even if that has a performance penalty, when the system
since before 1.0 I believe 8)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More
Hi,
first of all, I am not complaining, or calling things buggy. I know
that what I am running is "work in progress" and that one gets what one
deserves :-) 2.4.x has been stable for me and given me no severe problem
besides the changed pcmcia/cardbus support somewhere in 2.4.4-acx
Just let me
This is 2.4.5 with Andrea Arcangeli's aa1 patch compiled with himem:
Why is kswapd using so much CPU? If you reboot the machine and run the
same user process kswapd CPU usage is almost 0% and none of the swap is
used. This machine was upgraded from 2.2 and we did not have the luxury of
re-parti
I'd be forced to agree. I have 2.4.x in limited production, and with
the exception of the HP/APIC fatal issues that have a "noapic"
work-around, I have had no problem at all with any of the 2.4.x kernels
I've used.
Open software by definition will never reach the kind of monolithic
stability
This is my first email to the list. I'm not subscribed but I've read it
for years.
I don't agree with those claiming that 2.4.xx is bad or still beta.
We the administrators have the responsability to test early kernels and
send good bug reports so the developers can solve the bugs. That's the
w
On Fri, 1 Jun 2001, Marcin Kowalski wrote:
> Relating to Huge Dcache and InodeCache Entries and < 2xMem Swap.
> I have a server with > 1.1gig of RAM which I have limited to 1gig (due to
> stability - BUG at HIGHMEM.c: 155 crashes)...
>
> The size of the Swap space is 620mb... my memory usage i
I have a 2.4.5-ac3 box with 1G RAM and 2.6G Swapfirst time
developers hit apache/php/zendcache after reboot and it swapped to a stop.
I stop/restarted apache and it seems very happy...can't goto production like this tho
:(
Alan Cox wrote:
> > My system has 128 Meg of Swap and RAM.
>
> L
I don't know myself, (it sounds like other bigmem problems), but setting up a
2GB swap file is easy enough to test. :-)
-Dave
On Fri, Jun 01, 2001 at 10:29:39AM +0200, Marcin Kowalski wrote:
>
> I found this post of interest. I have 1.1 Gig of RAM but only 800mb of
> Swap as I expect NOT to us
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
gt; >
> > > My system has 128 Meg of Swap and RAM.
> > >
> > > Trever Adams
> > >
> > > -
> > > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> > > the body of a message to [EMAIL PROTECTED]
>
gt; > the body of a message to [EMAIL PROTECTED]
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
> > Please read the FAQ at http://www.tux.org/lkml/
>
> I've found that with the latest kernel release (2.4.5) VM performance has
> been greatly improv
Christopher Zimmerman wrote:
>
> I've found that with the latest kernel release (2.4.5) VM performance has
> been greatly improved. kswapd and bdflush no longer use 200% of my cpu
> cycles when simply doing a dd bs=1024 count=8388608 if=/dev/zero
> of=test.file. All of my
Please read the FAQ at http://www.tux.org/lkml/
I've found that with the latest kernel release (2.4.5) VM performance has
been greatly improved. kswapd and bdflush no longer use 200% of my cpu
cycles when simply doing a dd bs=1024 count=8388608 if=/dev/zero
of=test.file. All of my t
> Actually I have tried 1x,2x,3x. In 2.4.0 to 2.4.3 I had some issues but
> never a system freeze of any kind. With 2.4.4 I had more problems, but
> I was ok. 2.4.5 I now have these freezes. Maybe I should go back to
> 2x, but I still find this behavior crazy.
> This still doesn't negate th
> My system has 128 Meg of Swap and RAM.
Linus 2.4.0 notes are quite clear that you need at least twice RAM of swap
with 2.4.
Marcelo is working to change that but right now you are running something
explicitly explained as not going to work as you want
-
To unsubscribe from this list: send th
In my opinion 2.4.x is NOT ready for primetime. The VM has been getting
worse since 2.4.0, I believe. Definitely since and including 2.4.3. I
cannot even edit a few images in gimp where the entire working set used
to fit entirely in memory. The system now locks in some loop (SAK still
work
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 2
> 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
> > > >
> >
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'
wap:
> >
> > 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.
> >
>
> This bug known as the swap-reclaim bug has been there
08K used, 0K free 215744K cached
>
> Vanilla 2.4.5 VM.
I noticed that too and there is no way around it. If we assume
a 2.5xRAM target, you must add about 704MB. In my case I had no
spare partition so I added a swapfile, as undoubtedly many
2.4 sufferers did.
-- Pe
wap: 255608K av, 255608K used, 0K free 215744K
> cached
>
> Vanilla 2.4.5 VM.
>
This bug known as the swap-reclaim bug has been there for a while since
around 2.4.4. Rick van Riel said that it is in the TO-DO list.
Because of this, I went back to 2.2.20pre2aa1 on UP2000 SMP.
IM
f
> Swap: 255608K av, 255608K used, 0K free 215744K
> cached
>
> Vanilla 2.4.5 VM.
>
Sorry. I just looked at your numbers again and saw you have 133 MB of
real ram free. Is this during compile?
--
===
f
> Swap: 255608K av, 255608K used, 0K free 215744K
> cached
>
> Vanilla 2.4.5 VM.
I don't think this is new/unusual.
You can add the following to configure when compiling mysql ..
--with-low-memory Try to use less memory to compile to a
215744K
cached
Vanilla 2.4.5 VM.
--
Jeff Garzik | Disbelief, that's why you fail.
Building 1024|
MandrakeSoft |
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordom
57 matches
Mail list logo
