Date: Thu, 3 May 2007 14:25:02 -0700 (PDT)
From: david@lang.hm
To: David Schwartz <davids@webmaster.com>
cc: linux-kernel@vger.kernel.org
Subject: RE: scheduling oddity on 2.6.20.3 stock
In-Reply-To: <MDEHLPKNGKAHNMBLJOLKIEJKDIAC.davids@webmaster.com>
Message-ID: <Pine.LNX.4.64.0705031424030.26172@asgard.lang.hm>
References: <MDEHLPKNGKAHNMBLJOLKIEJKDIAC.davids@webmaster.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1324
Lines: 34

On Thu, 3 May 2007, David Schwartz wrote:

>> I needed to recompress some files from .bz2 to .gz so I setup a script to
>> do
>>
>> bunzip2 -c $file.bz2 |gzip -9 >$file.gz
>>
>> I expected that the two CPU heavy processes would end up on different
>> cpu's and spend a little time shuffling data between the two cpu's on a
>> system (dual core opteron)
>>
>> however, instead what I find is that each process is getting 50% of one
>> cpu while the other cpu is 97% idle.
>
> That would only be possible if the compression/decompression block size is
> small compared to the maximum pipe buffer size. I suspect the reverse is the
> case.
>
> It would be interesting to write an intermediate process that basically
> enlarged the pipe buffers and see if that changed anything. Basically, the
> intermediate process would allocate a large buffer (16MB or so) and fill it
> from 'bunzip2' while draining it to 'gzip' in a non-blocking way (unless the
> buffer was full/empty, of course).

hmm, how about
bunzip2 -c $file.bz2 |dd bs=8m |gzip -9 >$file.gz
should that work?

David Lang
-
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/