Re: [lc-devel] hello

[Bob A. <cu...@pb...>]

> > i patched 2.4.21rc2-ac2 , there were few trivial rejects, i didn't

> > i'll install this kernel on my firewall too, which is only non-smp
> > machine left :>

it works too. 
there is swap over NFS on this firewall , which benefited a _lot_ from 
compression and grouping of requests as it swaps over 10Mbit link.
_here_ i have problems with enabling swap via an file, it is possible 
_only_ via /dev/loop! swapping isn't very intensive, it swaps out some 
inactive data when i log in there and swaps out a bit more when i perform 
administrative tasks, but during normal operation it just swaps out inactive
shells, or inactive services. i felt difference though. compression ratio is 
around 41%!

btw. i lurked into code, and it seems compression algorithm is now determined 
automatically? or it can be changed somehow?

on lowmem systems implementing more complex algorithms would be obsolete, 
but when there is plenty of memory algorithm which would store large book
of possible words could greatly improve caching.
review www.autosophy.com
it is explained well there, and the idea is old and very well known.
if you're worried about legal problems -author (klaus holtz) answers to 
emails and will not have anything against using it, as it isn't really hard
to deduct how to make it by your own, and he just got the idea long time ago, 
before computing was so popular.





> >
> > btw. what are problems with making patch (or at least parts of it)
> > SMP-able?  i use openmosix patch making cluster out of few
> > single-cpu machines, and on oM group
> > (ope...@li...) one of programmers got
> > information about your patch recently, but never readed it (some
> > other user posted question wheter this and few others could be
> > merged into oM)
>
> I am very glad to hear that they talked about my patch in the
> openmosix mailing list. :-) To answer your question about what are the
> problems, I would say that the major problem now is time. As soon as I
> can get enough time (or I get help from other programmers), it will be
> done. Besides the bug you hit with loop device + swap file and a few
> bugs, to check and improve SMP support it one of the top items on my
> todo list.
>
> > i think at least swap compression support could be merged in.
> >
> > btw. performance - my laptop is a bit more responsive, stats show
> > about 50% compression ratio and lot of pages compressed.  one of
> > good things is that when it spins up disk (it is usually off) to
> > swap something in/out it doesn't 'freeze' system for time disk isn't
> > available.  i think it's because of grouping of swapout requests and
> > compressing them before swapping out (so instead of swap out some of
> > memory is just compressed waiting for disk to spin up, and then
> > -when disk is available-swapped out)
>
> A compressed cache that stores only pages backed by swap may improve
> your system in a number of scenarios, but not in as many as if we have
> page cache support. That is why I suggest you to test comp cache with
> page cache support when it is finally stable with swap files.
>
> BTW, I took a little longer to answer because first I wanted to
> perform some tests. I found out that there is a bug with swapfile
> support, because I guess comp cache code has never been tested with
> swap files, only with swap partitions. As soon as I created a swap
> file and ran with it, I hit some deadlocks. One is pretty obvious
> (shame on me!) and I will fix it asap (now I have to think a little
> how to solve it).
>
> > about swapfile - thanks for hint,
> > swapon swapfile.img works.
> > ofcourse i tested 2.4.21-rc2-ac2-cc with swap via /dev/loop0 before i
> > switched to more robust swap method :)
>
> Cool, it is a nicer solution that avoids the loop device overhead.
>
> Regards,

-- 
--