[lkml]   [2011]   [Aug]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: cleancache can lead to serious performance degradation
On 08/25/2011 11:56 AM, Dan Magenheimer wrote:

> Third, zcache is relatively new and can certainly benefit from
> the input of other developers. The lzo1x compression in the kernel
> is fairly slow; Seth Jennings (cc'ed) is looking into alternate
> compression technologies. Perhaps there is a better compression
> choice more suitable for older-slower processors, probably with a
> poorer compression ratio. Further, zcache currently does compression
> and decompression with interrupts disabled, which may be a
> significant factor in the slowdowns you've observed. This should
> be fixable.

This was something I've meaning to ask about. Why are compression
and decompression done with interrupts disabled? What would need
to change so that we don't have to disable interrupts?

>>> I guess that possible workaround could be to implement some kind of
>>> compression throttling valve for cleancache/zcache:
>>> - if there's available CPU time (idle cycles or so), then compress
>>> (maybe even with low CPU scheduler priority);
> Agreed, and this low-priority kernel thread ideally would also
> solve the "compress while irqs disabled" problem!


 \ /
  Last update: 2011-08-26 15:27    [W:0.063 / U:0.440 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site