On Thu, Mar 15, 2012 at 06:43:01PM +0100, Florian Schmaus wrote:
> On 03/15/12 17:37, Konrad Rzeszutek Wilk wrote:
> >On Tue, Mar 13, 2012 at 11:34:46AM +0100, Florian Schmaus wrote:
> >>From: Andor Daam<andor.daam@xxxxxxxxxxxxxx>
> >>
> >>This patch makes dynamic enabling/disabling of zcache via a sysfsnode possible.
> >There should be an patch to the Documentation/ABI/testing for these parameters.
> Agreed. Currently none of the modifiable zcache parameters has any
> Documentation in ABI/testing, including:
> - zv_max_zsize
> - zv_max_mean_zsize
> - zv_page_count_policy
Yeah, not sure how that was missed..
>
> We are also thinking about providing a patch that moves all read
> only zcache sysfs attributes into debugfs, so that the debug values
> from cleancache, frontswap and zcache are all within
> /sys/kernel/debug. It has also the advantage that if one doesn't
> want the performance impact of those counters, he could easily
> compile zcache without them.
Yup. Thought you want to keep in different directories.
> This patch could also include the missing Documentation.
Or another one.
> >>The node is used to toggle the preexisting zcache_freeze variable to
> >>stop/start accepting pages by zcache.
> >What is the reasoning to do this in the frontend instead of the backend (Cleancache/frontswap)?
> Not sure if you just confused frontend with backend. We always thought like
> frontend: cleancache/frontswap
> backend: zcache (or Xen tmem, ...)
Sure. That is one way to look at it. Next time I will say "the other end" :-)
>
> The reason to disable ("freeze") zcache via an mm/zcache sysfs
> interface is simply that this only affects zcache behavior and not
> the frontend(s) nor any other registered backend (which isn't
> currently possible anyways).
I am wondering whether the disabling could also be done in the
other end. And if that is a better choice? I am not saying "Do it that
way" - just thinking out loud whether doing the freeze on the other
end be more applicable?
>
> Florian
_______________________________________________
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxx
http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
