About Kernel Documentation Linux Kernel Contact Linux Resources Linux Blog

Documentation / vm / cleancache.txt




Custom Search

Based on kernel version 3.13. Page generated on 2014-01-20 22:05 EST.

1	MOTIVATION
2	
3	Cleancache is a new optional feature provided by the VFS layer that
4	potentially dramatically increases page cache effectiveness for
5	many workloads in many environments at a negligible cost.
6	
7	Cleancache can be thought of as a page-granularity victim cache for clean
8	pages that the kernel's pageframe replacement algorithm (PFRA) would like
9	to keep around, but can't since there isn't enough memory.  So when the
10	PFRA "evicts" a page, it first attempts to use cleancache code to
11	put the data contained in that page into "transcendent memory", memory
12	that is not directly accessible or addressable by the kernel and is
13	of unknown and possibly time-varying size.
14	
15	Later, when a cleancache-enabled filesystem wishes to access a page
16	in a file on disk, it first checks cleancache to see if it already
17	contains it; if it does, the page of data is copied into the kernel
18	and a disk access is avoided.
19	
20	Transcendent memory "drivers" for cleancache are currently implemented
21	in Xen (using hypervisor memory) and zcache (using in-kernel compressed
22	memory) and other implementations are in development.
23	
24	FAQs are included below.
25	
26	IMPLEMENTATION OVERVIEW
27	
28	A cleancache "backend" that provides transcendent memory registers itself
29	to the kernel's cleancache "frontend" by calling cleancache_register_ops,
30	passing a pointer to a cleancache_ops structure with funcs set appropriately.
31	Note that cleancache_register_ops returns the previous settings so that
32	chaining can be performed if desired. The functions provided must conform to
33	certain semantics as follows:
34	
35	Most important, cleancache is "ephemeral".  Pages which are copied into
36	cleancache have an indefinite lifetime which is completely unknowable
37	by the kernel and so may or may not still be in cleancache at any later time.
38	Thus, as its name implies, cleancache is not suitable for dirty pages.
39	Cleancache has complete discretion over what pages to preserve and what
40	pages to discard and when.
41	
42	Mounting a cleancache-enabled filesystem should call "init_fs" to obtain a
43	pool id which, if positive, must be saved in the filesystem's superblock;
44	a negative return value indicates failure.  A "put_page" will copy a
45	(presumably about-to-be-evicted) page into cleancache and associate it with
46	the pool id, a file key, and a page index into the file.  (The combination
47	of a pool id, a file key, and an index is sometimes called a "handle".)
48	A "get_page" will copy the page, if found, from cleancache into kernel memory.
49	An "invalidate_page" will ensure the page no longer is present in cleancache;
50	an "invalidate_inode" will invalidate all pages associated with the specified
51	file; and, when a filesystem is unmounted, an "invalidate_fs" will invalidate
52	all pages in all files specified by the given pool id and also surrender
53	the pool id.
54	
55	An "init_shared_fs", like init_fs, obtains a pool id but tells cleancache
56	to treat the pool as shared using a 128-bit UUID as a key.  On systems
57	that may run multiple kernels (such as hard partitioned or virtualized
58	systems) that may share a clustered filesystem, and where cleancache
59	may be shared among those kernels, calls to init_shared_fs that specify the
60	same UUID will receive the same pool id, thus allowing the pages to
61	be shared.  Note that any security requirements must be imposed outside
62	of the kernel (e.g. by "tools" that control cleancache).  Or a
63	cleancache implementation can simply disable shared_init by always
64	returning a negative value.
65	
66	If a get_page is successful on a non-shared pool, the page is invalidated
67	(thus making cleancache an "exclusive" cache).  On a shared pool, the page
68	is NOT invalidated on a successful get_page so that it remains accessible to
69	other sharers.  The kernel is responsible for ensuring coherency between
70	cleancache (shared or not), the page cache, and the filesystem, using
71	cleancache invalidate operations as required.
72	
73	Note that cleancache must enforce put-put-get coherency and get-get
74	coherency.  For the former, if two puts are made to the same handle but
75	with different data, say AAA by the first put and BBB by the second, a
76	subsequent get can never return the stale data (AAA).  For get-get coherency,
77	if a get for a given handle fails, subsequent gets for that handle will
78	never succeed unless preceded by a successful put with that handle.
79	
80	Last, cleancache provides no SMP serialization guarantees; if two
81	different Linux threads are simultaneously putting and invalidating a page
82	with the same handle, the results are indeterminate.  Callers must
83	lock the page to ensure serial behavior.
84	
85	CLEANCACHE PERFORMANCE METRICS
86	
87	If properly configured, monitoring of cleancache is done via debugfs in
88	the /sys/kernel/debug/mm/cleancache directory.  The effectiveness of cleancache
89	can be measured (across all filesystems) with:
90	
91	succ_gets	- number of gets that were successful
92	failed_gets	- number of gets that failed
93	puts		- number of puts attempted (all "succeed")
94	invalidates	- number of invalidates attempted
95	
96	A backend implementation may provide additional metrics.
97	
98	FAQ
99	
100	1) Where's the value? (Andrew Morton)
101	
102	Cleancache provides a significant performance benefit to many workloads
103	in many environments with negligible overhead by improving the
104	effectiveness of the pagecache.  Clean pagecache pages are
105	saved in transcendent memory (RAM that is otherwise not directly
106	addressable to the kernel); fetching those pages later avoids "refaults"
107	and thus disk reads.
108	
109	Cleancache (and its sister code "frontswap") provide interfaces for
110	this transcendent memory (aka "tmem"), which conceptually lies between
111	fast kernel-directly-addressable RAM and slower DMA/asynchronous devices.
112	Disallowing direct kernel or userland reads/writes to tmem
113	is ideal when data is transformed to a different form and size (such
114	as with compression) or secretly moved (as might be useful for write-
115	balancing for some RAM-like devices).  Evicted page-cache pages (and
116	swap pages) are a great use for this kind of slower-than-RAM-but-much-
117	faster-than-disk transcendent memory, and the cleancache (and frontswap)
118	"page-object-oriented" specification provides a nice way to read and
119	write -- and indirectly "name" -- the pages.
120	
121	In the virtual case, the whole point of virtualization is to statistically
122	multiplex physical resources across the varying demands of multiple
123	virtual machines.  This is really hard to do with RAM and efforts to
124	do it well with no kernel change have essentially failed (except in some
125	well-publicized special-case workloads).  Cleancache -- and frontswap --
126	with a fairly small impact on the kernel, provide a huge amount
127	of flexibility for more dynamic, flexible RAM multiplexing.
128	Specifically, the Xen Transcendent Memory backend allows otherwise
129	"fallow" hypervisor-owned RAM to not only be "time-shared" between multiple
130	virtual machines, but the pages can be compressed and deduplicated to
131	optimize RAM utilization.  And when guest OS's are induced to surrender
132	underutilized RAM (e.g. with "self-ballooning"), page cache pages
133	are the first to go, and cleancache allows those pages to be
134	saved and reclaimed if overall host system memory conditions allow.
135	
136	And the identical interface used for cleancache can be used in
137	physical systems as well.  The zcache driver acts as a memory-hungry
138	device that stores pages of data in a compressed state.  And
139	the proposed "RAMster" driver shares RAM across multiple physical
140	systems.
141	
142	2) Why does cleancache have its sticky fingers so deep inside the
143	   filesystems and VFS? (Andrew Morton and Christoph Hellwig)
144	
145	The core hooks for cleancache in VFS are in most cases a single line
146	and the minimum set are placed precisely where needed to maintain
147	coherency (via cleancache_invalidate operations) between cleancache,
148	the page cache, and disk.  All hooks compile into nothingness if
149	cleancache is config'ed off and turn into a function-pointer-
150	compare-to-NULL if config'ed on but no backend claims the ops
151	functions, or to a compare-struct-element-to-negative if a
152	backend claims the ops functions but a filesystem doesn't enable
153	cleancache.
154	
155	Some filesystems are built entirely on top of VFS and the hooks
156	in VFS are sufficient, so don't require an "init_fs" hook; the
157	initial implementation of cleancache didn't provide this hook.
158	But for some filesystems (such as btrfs), the VFS hooks are
159	incomplete and one or more hooks in fs-specific code are required.
160	And for some other filesystems, such as tmpfs, cleancache may
161	be counterproductive.  So it seemed prudent to require a filesystem
162	to "opt in" to use cleancache, which requires adding a hook in
163	each filesystem.  Not all filesystems are supported by cleancache
164	only because they haven't been tested.  The existing set should
165	be sufficient to validate the concept, the opt-in approach means
166	that untested filesystems are not affected, and the hooks in the
167	existing filesystems should make it very easy to add more
168	filesystems in the future.
169	
170	The total impact of the hooks to existing fs and mm files is only
171	about 40 lines added (not counting comments and blank lines).
172	
173	3) Why not make cleancache asynchronous and batched so it can
174	   more easily interface with real devices with DMA instead
175	   of copying each individual page? (Minchan Kim)
176	
177	The one-page-at-a-time copy semantics simplifies the implementation
178	on both the frontend and backend and also allows the backend to
179	do fancy things on-the-fly like page compression and
180	page deduplication.  And since the data is "gone" (copied into/out
181	of the pageframe) before the cleancache get/put call returns,
182	a great deal of race conditions and potential coherency issues
183	are avoided.  While the interface seems odd for a "real device"
184	or for real kernel-addressable RAM, it makes perfect sense for
185	transcendent memory.
186	
187	4) Why is non-shared cleancache "exclusive"?  And where is the
188	   page "invalidated" after a "get"? (Minchan Kim)
189	
190	The main reason is to free up space in transcendent memory and
191	to avoid unnecessary cleancache_invalidate calls.  If you want inclusive,
192	the page can be "put" immediately following the "get".  If
193	put-after-get for inclusive becomes common, the interface could
194	be easily extended to add a "get_no_invalidate" call.
195	
196	The invalidate is done by the cleancache backend implementation.
197	
198	5) What's the performance impact?
199	
200	Performance analysis has been presented at OLS'09 and LCA'10.
201	Briefly, performance gains can be significant on most workloads,
202	especially when memory pressure is high (e.g. when RAM is
203	overcommitted in a virtual workload); and because the hooks are
204	invoked primarily in place of or in addition to a disk read/write,
205	overhead is negligible even in worst case workloads.  Basically
206	cleancache replaces I/O with memory-copy-CPU-overhead; on older
207	single-core systems with slow memory-copy speeds, cleancache
208	has little value, but in newer multicore machines, especially
209	consolidated/virtualized machines, it has great value.
210	
211	6) How do I add cleancache support for filesystem X? (Boaz Harrash)
212	
213	Filesystems that are well-behaved and conform to certain
214	restrictions can utilize cleancache simply by making a call to
215	cleancache_init_fs at mount time.  Unusual, misbehaving, or
216	poorly layered filesystems must either add additional hooks
217	and/or undergo extensive additional testing... or should just
218	not enable the optional cleancache.
219	
220	Some points for a filesystem to consider:
221	
222	- The FS should be block-device-based (e.g. a ram-based FS such
223	  as tmpfs should not enable cleancache)
224	- To ensure coherency/correctness, the FS must ensure that all
225	  file removal or truncation operations either go through VFS or
226	  add hooks to do the equivalent cleancache "invalidate" operations
227	- To ensure coherency/correctness, either inode numbers must
228	  be unique across the lifetime of the on-disk file OR the
229	  FS must provide an "encode_fh" function.
230	- The FS must call the VFS superblock alloc and deactivate routines
231	  or add hooks to do the equivalent cleancache calls done there.
232	- To maximize performance, all pages fetched from the FS should
233	  go through the do_mpag_readpage routine or the FS should add
234	  hooks to do the equivalent (cf. btrfs)
235	- Currently, the FS blocksize must be the same as PAGESIZE.  This
236	  is not an architectural restriction, but no backends currently
237	  support anything different.
238	- A clustered FS should invoke the "shared_init_fs" cleancache
239	  hook to get best performance for some backends.
240	
241	7) Why not use the KVA of the inode as the key? (Christoph Hellwig)
242	
243	If cleancache would use the inode virtual address instead of
244	inode/filehandle, the pool id could be eliminated.  But, this
245	won't work because cleancache retains pagecache data pages
246	persistently even when the inode has been pruned from the
247	inode unused list, and only invalidates the data page if the file
248	gets removed/truncated.  So if cleancache used the inode kva,
249	there would be potential coherency issues if/when the inode
250	kva is reused for a different file.  Alternately, if cleancache
251	invalidated the pages when the inode kva was freed, much of the value
252	of cleancache would be lost because the cache of pages in cleanache
253	is potentially much larger than the kernel pagecache and is most
254	useful if the pages survive inode cache removal.
255	
256	8) Why is a global variable required?
257	
258	The cleancache_enabled flag is checked in all of the frequently-used
259	cleancache hooks.  The alternative is a function call to check a static
260	variable. Since cleancache is enabled dynamically at runtime, systems
261	that don't enable cleancache would suffer thousands (possibly
262	tens-of-thousands) of unnecessary function calls per second.  So the
263	global variable allows cleancache to be enabled by default at compile
264	time, but have insignificant performance impact when cleancache remains
265	disabled at runtime.
266	
267	9) Does cleanache work with KVM?
268	
269	The memory model of KVM is sufficiently different that a cleancache
270	backend may have less value for KVM.  This remains to be tested,
271	especially in an overcommitted system.
272	
273	10) Does cleancache work in userspace?  It sounds useful for
274	   memory hungry caches like web browsers.  (Jamie Lokier)
275	
276	No plans yet, though we agree it sounds useful, at least for
277	apps that bypass the page cache (e.g. O_DIRECT).
278	
279	Last updated: Dan Magenheimer, April 13 2011
Hide Line Numbers
About Kernel Documentation Linux Kernel Contact Linux Resources Linux Blog

Information is copyright its respective author. All material is available from the Linux Kernel Source distributed under a GPL License. This page is provided as a free service by mjmwired.net.