[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <6433bf44-2a68-485a-b048-a7aca241677d@default>
Date: Wed, 21 Jul 2010 10:37:20 -0700 (PDT)
From: Dan Magenheimer <dan.magenheimer@...cle.com>
To: ngupta@...are.org
Cc: Pekka Enberg <penberg@...helsinki.fi>,
Hugh Dickins <hugh.dickins@...cali.co.uk>,
Andrew Morton <akpm@...ux-foundation.org>,
Greg KH <greg@...ah.com>, Rik van Riel <riel@...hat.com>,
Avi Kivity <avi@...hat.com>,
Christoph Hellwig <hch@...radead.org>,
Minchan Kim <minchan.kim@...il.com>,
Konrad Wilk <konrad.wilk@...cle.com>,
linux-mm <linux-mm@...ck.org>,
linux-kernel <linux-kernel@...r.kernel.org>
Subject: RE: [PATCH 0/8] zcache: page cache compression support
> > Maybe the best solution is to make the threshold a sysfs
> > settable? Or maybe BOTH the single-page threshold and
> > the average threshold as two different sysfs settables?
> > E.g. throw away a put page if either it compresses poorly
> > or adding it to the pool would push the average over.
>
> Considering overall compression average instead of bothering about
> individual page compressibility seems like a good point. Still, I think
> storing completely incompressible pages isn't desirable.
>
> So, I agree with the idea of separate sysfs tunables for average and
> single-page
> compression thresholds with defaults conservatively set to 50% and
> PAGE_SIZE/2
> respectively. I will include these in "v2" patches.
Unless the single-page compression threshold is higher than the
average, the average is useless. IMHO I'd suggest at least
5*PAGE_SIZE/8 as the single-page threshold, possibly higher.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists