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

[Rik van Riel]

On 11/01/2011 05:43 PM, Andrew Morton wrote:

> I will confess to and apologise for dropping the ball on cleancache and
> frontswap.  I was never really able to convince myself that it met the
> (very vague) cost/benefit test,

I believe that it can, but if it does, we also have to
operate under the assumption that the major distros will
enable it.

This means that "no overhead when not compiled in" is
not going to apply to the majority of the users out there,
and we need clear numbers on what the overhead is when it
is enabled, but not used.

We also need an API that can handle arbitrarily heavy
workloads, since that is what people will throw at it
if it is enabled everywhere.

I believe that means addressing some of Andrea's concerns,
specifically that the API should be able to handle vectors
of pages and handle them asynchronously.

Even if the current back-ends do not handle that today,
chances are that (if tmem were to be enabled everywhere)
people will end up throwing workloads at tmem that pretty
much require such a thing.

An asynchronous interface would probably be a requirement
for something as high latency as encrypted ramster :)

API concerns like this are things that should be solved
before a merge IMHO, since afterwards we would end up with
the "we cannot change the API, because that breaks users"
scenario that we always end up finding ourselves in.
--
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/