Re: [GIT PULL] mm: frontswap (for 3.2 window)

[Clayton Weaver]

"So where I can I buy Network Attached Ram and skip all of
this byzantine VM complication?"

So let me see if I have this right: when the frontswap
back end fills up, the current design would force dumping
newer pages to real on-disk swap (to avoid OOM), possibly
compressed, while keeping older pages in the compressed
ram swap cache? It seems like it should just dump
(blocksize/pagesize) * pagesize multiples of its oldest
compressed pages to disk instead and store and compress
the new pages that are submitted to it, thus preserving
the "least recently used" logic in the frontswap backend.

A backend to frontswap should not be able to fail a put
at all (unless the whole machine or container is OOM and
no physical swap is configured, so the backend contains
no pages and has no space to allocate from).

-- 

Clayton Weaver
cgweav at fastmail dot fm

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/