|
Size: 1453
Comment:
|
Size: 2685
Comment:
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 1: | Line 1: |
| '''This page contains list of patches and other relatd code as it is being developed for Compressed Caching (for 2.6.x kernels) project. You can always find most up-to-date progress of code at [http://cvs.sourceforge.net/viewcvs.py/linuxcompressed/linux26 Project CVS]. The code is presently very raw but its helping me getting more experience with VMM code and how things are to be done :)''' | [:NitinGupta:Nitin Gupta] [[MailTo(nitingupta910 AT gmail DOT com)]] |
| Line 4: | Line 6: |
| * [attachment:toy%2Dcc%2D%32.%36.%31%36%2Drc%34.diff Toy ccache patch]: These are few lines I added to 2.6.16-rc4 while going through VMM code. Just some printk()s to simply highlight some kernel entry points for compressed caching work. | . This page contains some prototype code developed for CompressedCaching project. After seriously insufficient testing, each of these components were eventually merged into final implementation on 2.6.x kernels. ---- || [http://linuxcompressed.sourceforge.net/ Project Home Page] || CompressedCaching || [http://sourceforge.net/project/showfiles.php?group_id=13472 Patches] || === Compression algorithms to kernel mode: === Kernel module to test de/compression algorithms (WKdm, WK4x4, LZO): attachment:compress-test.tar.gz |
| Line 6: | Line 12: |
| * [attachment:patch%2Dcc%2D%32.%36.%31%36%2Dradix%2Dreplace%2Dstable.diff patch-cc-2.6.16-radix-replace-stable]: Replace original page (for now, only clean page cache pages) with a 'chunk head' when it is to be freed under memory pressure and simply store original page uncompressed. When page cache lookup is performed, again replace the 'chunk head' with original page. This patch uses simplified (and inefficient) locking in page cache lookup functions to make it stable for now. | There are basically three main algorithms that are well studied w.r.t compressed caching by previous works -- WKdm, WK4x4, LZO. |
| Line 8: | Line 14: |
| * [attachment:patch%2Dcc%2D%32.%36.%31%36%2Dbetter%2Dlocking%2Dunstable.diff patch-cc-2.6.16-better-locking-unstable]: This was an attempt to get a better (more efficint) locking in page cache lookup functions but it is not quite as stable as previous simplified patch. It causes apps to freeze as swap usage increase. | Of these, WKdm, WK4x4 are designed to handle anon pages (non filesystem pages) while LZO is more suitable for filesystem data. (Also, in general, compression speed is in order: WKdm > WK4x4 > LZO, while compression factor order is, in general, reverse). Now, all three algos are ported to kernel space - WKdm, WK4x4 and LZO. You can test them all using this module. It creates 3 /proc entries: /proc/compress-test/{compress, decompress, algo_idx} as described below: (for some detail see README with this module) ''' In short:''' __''Write to /proc/compress-test entries:''__ 1. ''compress'': compress data witten to it and store in internal buffer. 2. ''algo_idx'': write index of algo you want to test (0: WKdm, 1: WK4x4, 2: LZO) __''Read from /proc/compress-test entries:''__ 1. ''compress'': show original and compressed size (TODO: add other stats like time taken too) 2. ''decompress'': decompress compressed data stored in internal buffer. 3. ''algo_idx'': shows list of algos supported with their index. ---- ---- /!\ '''Edit conflict - other version:''' ---- . [[BR]] '' There was a university where computer science students could ask programming questions to faculty staff. [[BR]][[BR]] '' ---- /!\ '''Edit conflict - your version:''' ---- [[BR]]'' There was a university where computer science students could ask programming questions to faculty staff. [[BR]][[BR]] '' ---- /!\ '''End of edit conflict''' ---- ''However, before taking their problem and question to the staff, they first had to explain their problem and ask their question to a teddy bear in the lobby. Legend has it that 90% of the students found the answer to their question after putting their problem in words, just by asking it to the teddy bear. [[BR]][[BR]] '' ''They never needed to ask the staff, all they needed was to organize their thoughts.[[BR]] '' -- picked up from kernelnewbies.org |
[:NitinGupta:Nitin Gupta]
MailTo(nitingupta910 AT gmail DOT com)
This page contains some prototype code developed for CompressedCaching project. After seriously insufficient testing, each of these components were eventually merged into final implementation on 2.6.x kernels.
[http://linuxcompressed.sourceforge.net/ Project Home Page] |
[http://sourceforge.net/project/showfiles.php?group_id=13472 Patches] |
Compression algorithms to kernel mode:
Kernel module to test de/compression algorithms (WKdm, WK4x4, LZO): attachment:compress-test.tar.gz
There are basically three main algorithms that are well studied w.r.t compressed caching by previous works -- WKdm, WK4x4, LZO.
Of these, WKdm, WK4x4 are designed to handle anon pages (non filesystem pages) while LZO is more suitable for filesystem data. (Also, in general, compression speed is in order: WKdm > WK4x4 > LZO, while compression factor order is, in general, reverse).
Now, all three algos are ported to kernel space - WKdm, WK4x4 and LZO. You can test them all using this module. It creates 3 /proc entries: /proc/compress-test/{compress, decompress, algo_idx} as described below: (for some detail see README with this module)
In short:
Write to /proc/compress-test entries:
1. compress: compress data witten to it and store in internal buffer.
2. algo_idx: write index of algo you want to test (0: WKdm, 1: WK4x4, 2: LZO)
Read from /proc/compress-test entries:
1. compress: show original and compressed size (TODO: add other stats like time taken too)
2. decompress: decompress compressed data stored in internal buffer.
3. algo_idx: shows list of algos supported with their index.
![/!\](/moin_static1911/memodump/img/alert.png "/!\")
Edit conflict - other version:
There was a university where computer science students could ask programming questions to faculty staff. BRBR
- Edit conflict - your version:
BR There was a university where computer science students could ask programming questions to faculty staff. BRBR
- End of edit conflict
However, before taking their problem and question to the staff, they first had to explain their problem and ask their question to a teddy bear in the lobby. Legend has it that 90% of the students found the answer to their question after putting their problem in words, just by asking it to the teddy bear. BRBR
They never needed to ask the staff, all they needed was to organize their thoughts.BR -- picked up from kernelnewbies.org