* [2.4.20-ck7] good compressed caching experience @ 2003-05-26 18:50 Kimmo Sundqvist 2003-05-26 21:11 ` Con Kolivas 2003-05-27 1:21 ` Rodrigo Souza de Castro 0 siblings, 2 replies; 8+ messages in thread From: Kimmo Sundqvist @ 2003-05-26 18:50 UTC (permalink / raw) To: linux-kernel Hello I just decided to tell everyone that I've been able to run 2.4.20-ck7 with compressed caching enabled in my little brother's Pentium 133MHz, for hours, doing stress testing, compiling kernels and using the Internet under X. I had pre-empt enabled. Compressed swap worked also. I used 4kB pages without compressed swap, and 8kB with it. This was with Con's ck7pre versions released on 24th and 25th of May. Now running 2.4.20-ck7pre with compressed cache in a dual CPU machine with SMP disabled (compressed caching and SMP support are still mutually exclusive), 1GB of RAM but "mem=128M" for testing purposes. Been stable for 6 hours now, and done even some stress testing. Try 128 instances of burnBX with 1MB each, like "for ((A=128;A--;A<1)) do burnBX J & done". A nice brute force or "if you don't behave I'll push all my buttons" method :) Wondering if Pentium 133MHz (64MB RAM) is fast enough to benefit from compressed caching. I know there's a limit, depending on the speed of the CPU and the speed of the swap partition (doing random accesses), which determines if compressed caching is beneficial or not. This machine has a Seagate Barracuda V 80GB, which does sequential reads at 40MB/s. I could drive this into trashing, then type "sar -B 1 1000" and see how the swap is doing. Now, compressed caching brings me benefit if, and only if, it can compress and decompress pages faster than that in this CPU, which it sure does, since this is a Pentium III 933MHz, but I'm not sure about the little brother's Pentium 133MHz. It has a 4GB Seagate that does 6MB/s sequentially. Did I figure it out correctly? Of course swapping to a partition gets slower as the swap usage increases. Longer seeks and the like. Just a warning... both systems have only ReiserFS partitions. Other FSes might still get hurt. -Kimmo Sundqvist ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [2.4.20-ck7] good compressed caching experience 2003-05-26 18:50 [2.4.20-ck7] good compressed caching experience Kimmo Sundqvist @ 2003-05-26 21:11 ` Con Kolivas 2003-05-27 1:41 ` Rodrigo Souza de Castro 2003-05-27 14:13 ` Kimmo Sundqvist 2003-05-27 1:21 ` Rodrigo Souza de Castro 1 sibling, 2 replies; 8+ messages in thread From: Con Kolivas @ 2003-05-26 21:11 UTC (permalink / raw) To: Kimmo Sundqvist, linux-kernel; +Cc: rcastro On Tue, 27 May 2003 04:50, Kimmo Sundqvist wrote: > Hello Hi Kimmo > I just decided to tell everyone that I've been able to run 2.4.20-ck7 with > compressed caching enabled in my little brother's Pentium 133MHz, for > hours, doing stress testing, compiling kernels and using the Internet under > X. > > I had pre-empt enabled. Compressed swap worked also. I used 4kB pages > without compressed swap, and 8kB with it. > > This was with Con's ck7pre versions released on 24th and 25th of May. > > Now running 2.4.20-ck7pre with compressed cache in a dual CPU machine with > SMP disabled (compressed caching and SMP support are still mutually > exclusive), 1GB of RAM but "mem=128M" for testing purposes. Been stable > for 6 hours now, and done even some stress testing. Try 128 instances of > burnBX with 1MB each, like "for ((A=128;A--;A<1)) do burnBX J & done". A > nice brute force or "if you don't behave I'll push all my buttons" method > :) > > Wondering if Pentium 133MHz (64MB RAM) is fast enough to benefit from > compressed caching. I know there's a limit, depending on the speed of the > CPU and the speed of the swap partition (doing random accesses), which > determines if compressed caching is beneficial or not. > > This machine has a Seagate Barracuda V 80GB, which does sequential reads at > 40MB/s. I could drive this into trashing, then type "sar -B 1 1000" and > see how the swap is doing. Now, compressed caching brings me benefit if, > and only if, it can compress and decompress pages faster than that in this > CPU, which it sure does, since this is a Pentium III 933MHz, but I'm not > sure about the little brother's Pentium 133MHz. It has a 4GB Seagate that > does 6MB/s sequentially. Did I figure it out correctly? Of course > swapping to a partition gets slower as the swap usage increases. Longer > seeks and the like. What you describe has been my experience with cc as well. I haven't had any crashes or unusual problems with it since removing the AA vm changes as well - it seemed to be the combination that caused hiccups on extreme testing. >From what I can see, no matter how slow your cpu you will still get benefit from cc as the hard drives on those machines are proportionately slower as well. The one limitation of cc is that it does require _some_ ram to actually store swap pages in, and it seems that you need more than 32Mb ram to start deriving benefit. One minor thing, though - my vm hacks make compressed caching work much less than it normally does as they try to avoid swapping quite aggressively. It is when the vm attempts to start swapping that cc looks to see if it should take pages into compressed cache instead. I've cc'ed the actual developer of cc as he has indicated that he is actively working on compressed caching again. > Just a warning... both systems have only ReiserFS partitions. Other FSes > might still get hurt. This is definitely the case! If you try out compressed caching with ck7 please do not enable preempt if you are using ext2/3 or vfat. Cheers, Con ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [2.4.20-ck7] good compressed caching experience 2003-05-26 21:11 ` Con Kolivas @ 2003-05-27 1:41 ` Rodrigo Souza de Castro 2003-05-27 3:37 ` Con Kolivas 2003-05-27 14:13 ` Kimmo Sundqvist 1 sibling, 1 reply; 8+ messages in thread From: Rodrigo Souza de Castro @ 2003-05-27 1:41 UTC (permalink / raw) To: Con Kolivas; +Cc: Kimmo Sundqvist, linux-kernel, linuxcompressed-devel Hi Con, On Tue, May 27, 2003 at 07:11:34AM +1000, Con Kolivas wrote: > On Tue, 27 May 2003 04:50, Kimmo Sundqvist wrote: > > I just decided to tell everyone that I've been able to run 2.4.20-ck7 with > > compressed caching enabled in my little brother's Pentium 133MHz, for > > hours, doing stress testing, compiling kernels and using the Internet under > > X. > > > > I had pre-empt enabled. Compressed swap worked also. I used 4kB pages > > without compressed swap, and 8kB with it. [snip] > > exclusive), 1GB of RAM but "mem=128M" for testing purposes. Been stable > > for 6 hours now, and done even some stress testing. Try 128 instances of > > burnBX with 1MB each, like "for ((A=128;A--;A<1)) do burnBX J & done". A > > nice brute force or "if you don't behave I'll push all my buttons" method > > :) > > > > Wondering if Pentium 133MHz (64MB RAM) is fast enough to benefit from > > compressed caching. I know there's a limit, depending on the speed of the > > CPU and the speed of the swap partition (doing random accesses), which > > determines if compressed caching is beneficial or not. [snip] > What you describe has been my experience with cc as well. I haven't > had any crashes or unusual problems with it since removing the AA vm > changes as well - it seemed to be the combination that caused > hiccups on extreme testing. Something to be figured out yet. It is a pity we couldn't work harder on these problems. > >From what I can see, no matter how slow your cpu you will still get > benefit from cc as the hard drives on those machines are > proportionately slower as well. I guess that, in the past, the gap was smaller, but still there. > The one limitation of cc is that it does require _some_ ram to > actually store swap pages in, and it seems that you need more than > 32Mb ram to start deriving benefit. I am not sure. It requires some ram, but it is only a few pages to avoid failed page allocations when it first needs to allocate pages. I have a report of running CC on a laptop with 8M RAM, that showed to be a little more responsive. I don't have a scientific results showing that is better on system with a lower amount of memory, but this feedback seems positive. > One minor thing, though - my vm hacks make compressed caching work > much less than it normally does as they try to avoid swapping quite > aggressively. It is when the vm attempts to start swapping that cc > looks to see if it should take pages into compressed cache instead. What exactly are your VM hacks concerning CC? The default behaviour is to compress pages only when the VM starts freeing pages, not in a compress-ahead fashion, pretty much what I think you said above. > I've cc'ed the actual developer of cc as he has indicated that he is > actively working on compressed caching again. At a slower pace, but finally back to CC development. :-) > > Just a warning... both systems have only ReiserFS partitions. > > Other FSes might still get hurt. > > This is definitely the case! If you try out compressed caching with > ck7 please do not enable preempt if you are using ext2/3 or vfat. As told in a previous email, I wouldn't enable preempt in any case with this code version. Regards, -- Rodrigo ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [2.4.20-ck7] good compressed caching experience 2003-05-27 1:41 ` Rodrigo Souza de Castro @ 2003-05-27 3:37 ` Con Kolivas 0 siblings, 0 replies; 8+ messages in thread From: Con Kolivas @ 2003-05-27 3:37 UTC (permalink / raw) To: Rodrigo Souza de Castro Cc: Kimmo Sundqvist, linux-kernel, linuxcompressed-devel On Tue, 27 May 2003 11:41, Rodrigo Souza de Castro wrote: > Hi Con, > > On Tue, May 27, 2003 at 07:11:34AM +1000, Con Kolivas wrote: > > On Tue, 27 May 2003 04:50, Kimmo Sundqvist wrote: > > > I just decided to tell everyone that I've been able to run 2.4.20-ck7 > > > with compressed caching enabled in my little brother's Pentium 133MHz, > > > for hours, doing stress testing, compiling kernels and using the > > > Internet under X. > > > > > > I had pre-empt enabled. Compressed swap worked also. I used 4kB pages > > > without compressed swap, and 8kB with it. > > [snip] > > > > exclusive), 1GB of RAM but "mem=128M" for testing purposes. Been > > > stable for 6 hours now, and done even some stress testing. Try 128 > > > instances of burnBX with 1MB each, like "for ((A=128;A--;A<1)) do > > > burnBX J & done". A nice brute force or "if you don't behave I'll push > > > all my buttons" method > > > > > > :) > > > > > > Wondering if Pentium 133MHz (64MB RAM) is fast enough to benefit from > > > compressed caching. I know there's a limit, depending on the speed of > > > the CPU and the speed of the swap partition (doing random accesses), > > > which determines if compressed caching is beneficial or not. > > [snip] > > > What you describe has been my experience with cc as well. I haven't > > had any crashes or unusual problems with it since removing the AA vm > > changes as well - it seemed to be the combination that caused > > hiccups on extreme testing. > > Something to be figured out yet. It is a pity we couldn't work harder > on these problems. I think getting the stability necessary on the main tree was far more important so I don't regret this. > > > >From what I can see, no matter how slow your cpu you will still get > > > > benefit from cc as the hard drives on those machines are > > proportionately slower as well. > > I guess that, in the past, the gap was smaller, but still there. > > > The one limitation of cc is that it does require _some_ ram to > > actually store swap pages in, and it seems that you need more than > > 32Mb ram to start deriving benefit. > > I am not sure. It requires some ram, but it is only a few pages to > avoid failed page allocations when it first needs to allocate pages. I > have a report of running CC on a laptop with 8M RAM, that showed to be > a little more responsive. I don't have a scientific results showing > that is better on system with a lower amount of memory, but this > feedback seems positive. > > > One minor thing, though - my vm hacks make compressed caching work > > much less than it normally does as they try to avoid swapping quite > > aggressively. It is when the vm attempts to start swapping that cc > > looks to see if it should take pages into compressed cache instead. > > What exactly are your VM hacks concerning CC? The default behaviour is > to compress pages only when the VM starts freeing pages, not in a > compress-ahead fashion, pretty much what I think you said above. Ok, I didn't look at your code, but that would make sense too because with my hacks it will start even lower priority than the default VM freeing less pages at a time unless the memory pressure gets high. > > > I've cc'ed the actual developer of cc as he has indicated that he is > > actively working on compressed caching again. > > At a slower pace, but finally back to CC development. :-) Excellent. Good to have you back. > > > > Just a warning... both systems have only ReiserFS partitions. > > > Other FSes might still get hurt. > > > > This is definitely the case! If you try out compressed caching with > > ck7 please do not enable preempt if you are using ext2/3 or vfat. > > As told in a previous email, I wouldn't enable preempt in any case > with this code version. -ck has always come with a warning saying as much. I hope to integrate more of your code when you're happy with it, so this problem can be resolved. Cheers, Con ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [2.4.20-ck7] good compressed caching experience 2003-05-26 21:11 ` Con Kolivas 2003-05-27 1:41 ` Rodrigo Souza de Castro @ 2003-05-27 14:13 ` Kimmo Sundqvist 2003-05-27 14:20 ` Con Kolivas 2003-05-28 2:00 ` Rodrigo Souza de Castro 1 sibling, 2 replies; 8+ messages in thread From: Kimmo Sundqvist @ 2003-05-27 14:13 UTC (permalink / raw) To: linux-kernel; +Cc: rcastro, Con Kolivas On Tuesday 27 May 2003 00:11, Con Kolivas wrote: > On Tue, 27 May 2003 04:50, Kimmo Sundqvist wrote: > > Just a warning... both systems have only ReiserFS partitions. Other FSes > > might still get hurt. > This is definitely the case! If you try out compressed caching with ck7 > please do not enable preempt if you are using ext2/3 or vfat. Is this a problem in ext2/3, pre-empt implementation, compressed caching or kernel in general? I think I can still choose between compression methods, or can I? Which one of them, on average, is the least CPU-intensive, and which one gives the best compression ratio? I am also at loss how to interpret the percentages in "cat /proc/comp_cache_stat". For M$ Windows there was once a program called MagnaRAM97 that had a similar idea, but I don't understand how it could report 2 to 3-fold compression ratios. It always spontaneously rebooted the Pentium 133MHz after some hours, so I uninstalled it. Just take your time, but will we see a pre-empt safe (or better yet SMP safe) version coming out anytime soon? Compiling another 2.4.20-ck7 with 8kB pages and swap compression in the background. I have now "mem=896M" to avoid the highmem boundary, even if it wasn't necessary. Someone said somewhere that a 1GB system is faster without highmem support, so I haven't compiled it in for a while. -Kimmo S. ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [2.4.20-ck7] good compressed caching experience 2003-05-27 14:13 ` Kimmo Sundqvist @ 2003-05-27 14:20 ` Con Kolivas 2003-05-28 2:00 ` Rodrigo Souza de Castro 1 sibling, 0 replies; 8+ messages in thread From: Con Kolivas @ 2003-05-27 14:20 UTC (permalink / raw) To: Kimmo Sundqvist, linux-kernel; +Cc: rcastro On Wed, 28 May 2003 00:13, Kimmo Sundqvist wrote: > On Tuesday 27 May 2003 00:11, Con Kolivas wrote: > > On Tue, 27 May 2003 04:50, Kimmo Sundqvist wrote: > > > Just a warning... both systems have only ReiserFS partitions. Other > > > FSes might still get hurt. > > > > This is definitely the case! If you try out compressed caching with ck7 > > please do not enable preempt if you are using ext2/3 or vfat. > > Is this a problem in ext2/3, pre-empt implementation, compressed caching or > kernel in general? The compressed caching code isn't yet properly preempt aware. The filesystems that are safe are just lucky. > > I think I can still choose between compression methods, or can I? Which > one of them, on average, is the least CPU-intensive, and which one gives > the best compression ratio? I am also at loss how to interpret the > percentages in "cat /proc/comp_cache_stat". The default in -ck7 is lzo which is the best compression and pretty fast. The full details only RCastro can tell us. > > For M$ Windows there was once a program called MagnaRAM97 that had a > similar idea, but I don't understand how it could report 2 to 3-fold > compression ratios. It always spontaneously rebooted the Pentium 133MHz > after some hours, so I uninstalled it. > > Just take your time, but will we see a pre-empt safe (or better yet SMP > safe) version coming out anytime soon? > > Compiling another 2.4.20-ck7 with 8kB pages and swap compression in the > background. I have now "mem=896M" to avoid the highmem boundary, even if > it wasn't necessary. Someone said somewhere that a 1GB system is faster > without highmem support, so I haven't compiled it in for a while. Definitely with the default VM as the basis in 2.4 (as opposed to AA or RMAP) you are much better off without High Mem enabled if you only have 1Gb. Con ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [2.4.20-ck7] good compressed caching experience 2003-05-27 14:13 ` Kimmo Sundqvist 2003-05-27 14:20 ` Con Kolivas @ 2003-05-28 2:00 ` Rodrigo Souza de Castro 1 sibling, 0 replies; 8+ messages in thread From: Rodrigo Souza de Castro @ 2003-05-28 2:00 UTC (permalink / raw) To: Kimmo Sundqvist; +Cc: linux-kernel, Con Kolivas, linuxcompressed-deve Hey Kimmo, On Tue, May 27, 2003 at 05:13:48PM +0300, Kimmo Sundqvist wrote: > On Tuesday 27 May 2003 00:11, Con Kolivas wrote: > > On Tue, 27 May 2003 04:50, Kimmo Sundqvist wrote: > > > Just a warning... both systems have only ReiserFS partitions. Other FSes > > > might still get hurt. > > > This is definitely the case! If you try out compressed caching with ck7 > > please do not enable preempt if you are using ext2/3 or vfat. > > Is this a problem in ext2/3, pre-empt implementation, compressed caching or > kernel in general? It is a compressed caching problem. As Con said, FSs that are safe are just lucky. > I think I can still choose between compression methods, or can I? You can, just use the kernel parameter "compalg=" kernel parameter. compalg=0 (WKdm) compalg=1 (WK4x4) compalg=2 (LZO, default) > Which one of them, on average, is the least CPU-intensive, and which > one gives the best compression ratio? I am also at loss how to > interpret the percentages in "cat /proc/comp_cache_stat". LZO is the most CPU-intensive and gives the best compression ratio. Even if spending more CPU cycles to compress than WKdm or WK4x4, it showed to have the best performance given its compression ratio. > For M$ Windows there was once a program called MagnaRAM97 that had a > similar idea, but I don't understand how it could report 2 to 3-fold > compression ratios. It always spontaneously rebooted the Pentium > 133MHz after some hours, so I uninstalled it. I am not sure, but I guess the purpose of MagnaRAM and this patch are different, as well as the approach. This patch intends to reduce the number of disk accesses using compression and extending effective memory size, therefore improving general performance. We use an adaptive cache size to avoid overhead when compression isn't/wouldn't help. > Just take your time, but will we see a pre-empt safe (or better yet > SMP safe) version coming out anytime soon? Yes, you will, they are the top items on my todo list. > Compiling another 2.4.20-ck7 with 8kB pages and swap compression in > the background. I have now "mem=896M" to avoid the highmem > boundary, even if it wasn't necessary. Someone said somewhere that > a 1GB system is faster without highmem support, so I haven't > compiled it in for a while. Best regards, -- Rodrigo ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [2.4.20-ck7] good compressed caching experience 2003-05-26 18:50 [2.4.20-ck7] good compressed caching experience Kimmo Sundqvist 2003-05-26 21:11 ` Con Kolivas @ 2003-05-27 1:21 ` Rodrigo Souza de Castro 1 sibling, 0 replies; 8+ messages in thread From: Rodrigo Souza de Castro @ 2003-05-27 1:21 UTC (permalink / raw) To: Kimmo Sundqvist; +Cc: linux-kernel, linuxcompressed-devel Hi Kimmo! On Mon, May 26, 2003 at 09:50:03PM +0300, Kimmo Sundqvist wrote: > I just decided to tell everyone that I've been able to run > 2.4.20-ck7 with compressed caching enabled in my little brother's > Pentium 133MHz, for hours, doing stress testing, compiling kernels > and using the Internet under X. Great, glad to know that. > I had pre-empt enabled. Compressed swap worked also. I used 4kB > pages without compressed swap, and 8kB with it. Compressed cache patch isn't safe to be used with preempt, at least not with the version you tried (0.24pre5). There are some bug reports that I was able to check myself about fs corruptions (due to problems in locking control). The latest code seems to fix these corruptions, given some tests some volunteers and I performed. I ported this code to 2.4.20, but I still couldn't figure out why it isn't as stable as in 2.4.18 version, that is why it remains unreleased as a patch (although it is in the CVS server). Double page size (i.e, 8K pages) is useful when you don't have a good compression ratio. If your data compress to more than 50% of its original size, a compressed cache with 4K isn't supposed to provide major performance gains. > This was with Con's ck7pre versions released on 24th and 25th of > May. > > Now running 2.4.20-ck7pre with compressed cache in a dual CPU > machine with SMP disabled (compressed caching and SMP support are > still mutually exclusive), Until I make it work safely on SMP systems, I want to make it exclusive in the config.in. > 1GB of RAM but "mem=128M" for testing purposes. Been stable for 6 > hours now, and done even some stress testing. Try 128 instances of > burnBX with 1MB each, like "for ((A=128;A--;A<1)) do burnBX J & > done". A nice brute force or "if you don't behave I'll push all my > buttons" method :) :-) > Wondering if Pentium 133MHz (64MB RAM) is fast enough to benefit > from compressed caching. I know there's a limit, depending on the > speed of the CPU and the speed of the swap partition (doing random > accesses), which determines if compressed caching is beneficial or > not. That's right. Faster CPUs have a greater tendency to benefit from compressed caching, since the gap between them and disks is larger. This gap is the basic principle that makes compressed caching interesting today. > This machine has a Seagate Barracuda V 80GB, which does sequential > reads at 40MB/s. I could drive this into trashing, then type "sar > -B 1 1000" and see how the swap is doing. Now, compressed caching > brings me benefit if, and only if, it can compress and decompress > pages faster than that in this CPU, which it sure does, since this > is a Pentium III 933MHz, but I'm not sure about the little brother's > Pentium 133MHz. It has a 4GB Seagate that does 6MB/s sequentially. > Did I figure it out correctly? Of course swapping to a partition > gets slower as the swap usage increases. Longer seeks and the like. Yes, you figured it out correctly. I don't know the lower limit for a CPU to benefit from compressed caching. However I guess that, since we already had a gap between disk and CPU with a Pentium 133 MHz, it will probably have some advantage using it, even if not as much as with a faster CPU. The current code was written and tested on a Pentium III 1 GHz CPU, so there may be room for improvements for such systems, as your Pentium 133 MHz. I would like to know your impressions about compressed caching on your brother's system. > Just a warning... both systems have only ReiserFS partitions. Other > FSes might still get hurt. True. I don't know how you don't have your filesystem corrupted though. I suggest you to disable preempt if you want to keep testing this compressed cache code in order to avoid possible problems (and you getting mad at me :-). Thanks for your feedback. Regards, -- Rodrigo ^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2003-05-28 1:47 UTC | newest] Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2003-05-26 18:50 [2.4.20-ck7] good compressed caching experience Kimmo Sundqvist 2003-05-26 21:11 ` Con Kolivas 2003-05-27 1:41 ` Rodrigo Souza de Castro 2003-05-27 3:37 ` Con Kolivas 2003-05-27 14:13 ` Kimmo Sundqvist 2003-05-27 14:20 ` Con Kolivas 2003-05-28 2:00 ` Rodrigo Souza de Castro 2003-05-27 1:21 ` Rodrigo Souza de Castro
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).