On 07/27/2014 04:47 PM, Nick Krause wrote: > This may be a bad idea , but compression in brtfs seems to be only > using one core to compress. > Depending on the CPU used and the amount of cores in the CPU we can > make this much faster > with multiple cores. This seems bad by my reading at least I would > recommend for writing compression > we write a function to use a certain amount of cores based on the load > of the system's CPU not using > more then 75% of the system's CPU resources as my system when idle has > never needed more > then one core of my i5 2500k to run when with interrupts for opening > eclipse are running. For reading > compression on good core seems fine to me as testing other compression > software for reads , it's > way less CPU intensive. > Cheers Nick We would probably get a bigger benefit from taking an approach like SquashFS has recently added, that is, allowing multi-threaded decompression fro reads, and decompressing directly into the pagecache. Such an approach would likely make zlib compression much more scalable on large systems.
smime.p7s
Description: S/MIME Cryptographic Signature