Lines Matching refs:it

12 Frontswap is so named because it can be thought of as the opposite of
20 frontswap_ops funcs appropriately and the functions it provides must
25 copy the page to transcendent memory and associate it with the type and
34 succeed.  So when the kernel finds itself in a situation where it needs
35 to swap out a page, it first attempts to use frontswap.  If the store returns
95 i.e. when system A is overcommitted, it can swap to system B, and
104 it well with no kernel changes have essentially failed (except in some
129 request (i.e. provides no memory despite claiming it might),
157 accessible by the kernel.  Exactly how much memory it provides is
167 consults with the frontswap backend and if the backend says it does NOT
170 backend is unpredictable to the kernel; it may choose to never accept a
171 page, it could accept every ninth page, or it might accept every
176 corresponding to the page offset on the swap device to which it would
180 it first calls frontswap_load() which checks the frontswap_map to
182 it was, the page of data is filled from the frontswap backend and
196 swap hierarchy.  Perhaps it could be rewritten to accommodate a hierarchy,
197 but this would require fairly drastic changes.  Even if it were
199 assumes a swap device is fixed size and any page in it is linearly
206 backends because it grants completely dynamic discretion to the
227 (or host OS) to do "intelligent overcommit".  For example, it can
236 and the possibility that it might hold no pages at all.  This means
241 some kind of "ghost" swap device and ensure that it is never used.
244    has been previously successfully stored, can't it always be
247 Nearly always it can, but no, sometimes it cannot.  Consider an example
252 frontswap rejects a store that would overwrite, it also must invalidate
253 the old data and ensure that it is no longer accessible.  Since the