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

[KAMEZAWA Hiroyuki]

On Tue, 1 Nov 2011 08:25:38 -0700 (PDT)
Dan Magenheimer <dan.magenheimer@xxxxxxxxxx> wrote:

> >   - At discussing an fujitsu user support guy (just now), he asked
> >     'why it's not designed as device driver ?"
> >     I couldn't answered.
> > 
> >     So, I have small concerns with frontswap.ops ABI design.
> >     Do we need ABI and other modules should be pluggable ?
> >     Can frontswap be implemented as something like
> > 
> >     # setup frontswap via device-mapper or some.
> >     # swapon /dev/frontswap
> >     ?
> >     It seems required hooks are just before/after read/write swap device.
> >     other hooks can be implemented in notifier..no ?
> 
> A good question, and it is answered in FAQ #4 included in
> the patchset (Documentation/vm/frontswap.txt).  The short
> answer is that the tmem ABI/API used by frontswap is
> intentionally very very dynamic -- ANY attempt to put
> a page into it can be rejected by the backend.  This is
> not possible with block I/O or swap, at least without
> a massive rewrite.  And this dynamic capability is the
> key to supporting the many users that frontswap supports.
> 
Hmm.

> By the way, what your fujitsu user support guy suggests is
> exactly what zram does.  The author of zram (Nitin Gupta)
> agrees that frontswap has many advantages over zram,
> see https://lkml.org/lkml/2011/10/28/8 and he supports
> merging frontswap.  And Ed Tomlinson, a current user
> of zram says that he would use frontswap instead of
> zram: https://lkml.org/lkml/2011/10/29/53 
> 
> Kame, can I add you to the list of people who support
> merging frontswap, assuming more good performance numbers
> are posted?
> 
Before answer, let me explain my attitude to this project.

As hobby, I like this kind of work which allows me to imagine what kind
of new fancy features it will allow us. Then, I reviewed patches.

As people who sells enterprise system and support, I can't recommend this
to our customers. IIUC, cleancache/frontswap/zcache hides its avaiable
resources from user's view and making the system performance unvisible and
not-predictable. That's one of the reason why I asksed whether or not
you have plans to make frontswap(cleancache) cgroup aware.
(Hmm, but at making a product which offers best-effort-performance to customers,
 this project may make sense. But I am not very interested in best-effort
 service very much.)

I wonder if there are 'static size simple victim cache per cgroup' project
under frontswap/cleancache and it helps all user's workload isolation
even if there is no VM or zcache, tmem.  It sounds wonderful.

So, I'd like to ask whether you have any enhancement plans in future ?
rather than 'current' peformance. The reason I hesitate to say "Okay!",
is that I can't see enterprise usage of this, a feature which cannot
be controlled by admins and make perfomrance prediction difficult in busy system.

Thanks,
-Kame

--
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/