lkml.org 
[lkml]   [2003]   [May]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [2.4.20-ck7] good compressed caching experience
Date
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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:35    [W:0.339 / U:0.048 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site