memory compress tech...

memory compress tech...

[lkthomas]

another suggestion, mate
if you are using dos before, you must know a tools call "QEMM" 
http://www.netten.net/~garycox/qemm3.htm
you can look over this URL if you do not know what is that
it can do a real time memory compress and decompress tools ( I mean on fly ), the sound like IBM of MXT..
so people can use more memory as they want
but IBM one can not compile into kernel :(
so I am thinking if someone can program a new code into kernel and let user to select if use it or not
( 8M data in RAM can compress to 4-5M, so people can free up more to use in another side )
I hope this one would help for end user :)
Thanks

Re: memory compress tech...

[Ignacio Vazquez-Abrams]

On Tue, 14 Aug 2001 lkthomas@hkicable.com wrote:

> another suggestion, mate
> if you are using dos before, you must know a tools call "QEMM"
> http://www.netten.net/~garycox/qemm3.htm
> you can look over this URL if you do not know what is that
> it can do a real time memory compress and decompress tools ( I mean on fly ), the sound like IBM of MXT..
> so people can use more memory as they want
> but IBM one can not compile into kernel :(
> so I am thinking if someone can program a new code into kernel and let user to select if use it or not
> ( 8M data in RAM can compress to 4-5M, so people can free up more to use in another side )
> I hope this one would help for end user :)
> Thanks

Here's a text blurb from the page mentioned:

"Various reports from various reviews that I have seen have indicated Magnaram
[QEMM's memory compression program] doesn't help very much and in fact can
really slow down your system. In my tests I found a slight system speed
decrease and I really couldn't tell if it was helping me any or not... On my
system I have MagnaRAM turned off. Having enough physical RAM in a system
ALWAYS outperforms any other way of getting around an insufficent memory
problem."

I think he said it best. There may be uses for memory-compression technology,
but does that make the slow-down worthwhile?

-- 
Ignacio Vazquez-Abrams  <ignacio@openservices.net>

Re: memory compress tech...

[Martin Dalecki]

Ignacio Vazquez-Abrams wrote:
> 
> On Tue, 14 Aug 2001 lkthomas@hkicable.com wrote:
> 
> > another suggestion, mate
> > if you are using dos before, you must know a tools call "QEMM"
> > http://www.netten.net/~garycox/qemm3.htm
> > you can look over this URL if you do not know what is that
> > it can do a real time memory compress and decompress tools ( I mean on fly ), the sound like IBM of MXT..
> > so people can use more memory as they want
> > but IBM one can not compile into kernel :(
> > so I am thinking if someone can program a new code into kernel and let user to select if use it or not
> > ( 8M data in RAM can compress to 4-5M, so people can free up more to use in another side )
> > I hope this one would help for end user :)
> > Thanks
> 
> Here's a text blurb from the page mentioned:
> 
> "Various reports from various reviews that I have seen have indicated Magnaram
> [QEMM's memory compression program] doesn't help very much and in fact can
> really slow down your system. In my tests I found a slight system speed
> decrease and I really couldn't tell if it was helping me any or not... On my
> system I have MagnaRAM turned off. Having enough physical RAM in a system
> ALWAYS outperforms any other way of getting around an insufficent memory
> problem."
> 
> I think he said it best. There may be uses for memory-compression technology,
> but does that make the slow-down worthwhile?

Please read the corresponding research papers by IBM on this
topic. It's all NOT ABOUT RAM size. It is all bout BUS BADWIDTH!
At least if you do it properly - namely in hardware... ;-)

Re: memory compress tech...

[Ted Unangst]

On Mon, 13 Aug 2001, Martin Dalecki wrote:

> Ignacio Vazquez-Abrams wrote:
> >
> > I think he said it best. There may be uses for memory-compression technology,
> > but does that make the slow-down worthwhile?
>
> Please read the corresponding research papers by IBM on this
> topic. It's all NOT ABOUT RAM size. It is all bout BUS BADWIDTH!
> At least if you do it properly - namely in hardware... ;-)

maybe for compressing swap?  you have to read less data off the disk,
which is faster.  and the processor is probably idling anyway, waiting on
disk.






--
"The brave men who died in Vietnam, more than 100% of which were
black, were the ultimate sacrifice."
      - M. Barry, Mayor of Washington, DC

Re: memory compress tech...

[Ignacio Vazquez-Abrams]

On Tue, 14 Aug 2001, Ted Unangst wrote:

> maybe for compressing swap?  you have to read less data off the disk,
> which is faster.  and the processor is probably idling anyway, waiting on
> disk.

Ah, now THAT is a good idea.

Compressing groups of pages, probably 16k at a time, and storing them on 20k
boundaries will result in a loss of swap space but a probable increase in
speed. And the boundary alignment will probably simplify bookkeeping. You
shouldn't be using swap anyways, so a 20% loss probably isn't a huge deal.

Maybe someone with a little more experience in the area of swap management
under Linux should take over the discussion from here...

-- 
Ignacio Vazquez-Abrams  <ignacio@openservices.net>

Re: memory compress tech...

[Dave Jones]

On Tue, 14 Aug 2001, Ignacio Vazquez-Abrams wrote:

> > maybe for compressing swap?  you have to read less data off the disk,
> > which is faster.  and the processor is probably idling anyway, waiting on
> > disk.
> Ah, now THAT is a good idea.

I missed the beginning of this thread, but this sounds to me like
what is being implemented at http://linuxcompressed.sourceforge.net/

regards,

Dave.

-- 
| Dave Jones.        http://www.suse.de/~davej
| SuSE Labs

Re: memory compress tech...

[Ignacio Vazquez-Abrams]

On Tue, 14 Aug 2001, Dave Jones wrote:

> On Tue, 14 Aug 2001, Ignacio Vazquez-Abrams wrote:
>
> > > maybe for compressing swap?  you have to read less data off the disk,
> > > which is faster.  and the processor is probably idling anyway, waiting on
> > > disk.
> > Ah, now THAT is a good idea.
>
> I missed the beginning of this thread, but this sounds to me like
> what is being implemented at http://linuxcompressed.sourceforge.net/
>
> regards,
>
> Dave.

The original message talked about duplicating QEMM's MagnaRAM (a RAM
compression utility) under Linux, which seems to be part of what the page at
the URL describes. They say that they're not aiming for performance right now,
and I can believe that (their numbers are quite iffy).

They also do go over compressed swap, and after looking at point IV in section
4 of their design considerations, they seem to be headed in the right
direction.

I think maybe I'll go help...

-- 
Ignacio Vazquez-Abrams  <ignacio@openservices.net>