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

[Dan Magenheimer]

> From: Andrea Arcangeli [mailto:aarcange@xxxxxxxxxx]
> Subject: Re: [GIT PULL] mm: frontswap (for 3.2 window)
> 
> On Fri, Oct 28, 2011 at 10:07:12AM -0700, Dan Magenheimer wrote:
> > First, there are several companies and several unaffiliated kernel
> > developers contributing here, building on top of frontswap.  I happen
> > to be spearheading it, and my company is backing me up.  (It
> > might be more appropriate to note that much of the resistance comes
> > from people of your company... but please let's keep our open-source
> > developer hats on and have a technical discussion rather than one
> > which pleases our respective corporate overlords.)
> 
> Fair enough to want an independent review but I'd be interesting to
> also know how many of the several companies and unaffiliated kernel
> developers are contributing to it that aren't using tmem with Xen.

Well just to summarize the non-Oracle-non-tmem supportive responses so far
to this frontswap thread:

Nitin Gupta, for zcache
Brian King (IBM), for Linux on Power
Sasha Levin and Neo Jia, affiliation unspecified, working on tmem for KVM
Ed Tomlinson, affiliation unspecified, end-user of zcache

This doesn't count those that replied offlist to Linus to support the
merging of cleancache earlier this year, and doesn't count the fair
number of people who have offlist asked me about zcache or if KVM
supports tmem or when RAMster will be ready.  I suppose I could
do a better job advertising others' interest...

> Note, Hugh is working for another company... and they're using cgroups
> not KVM nor Xen, so I suggests he'd be a fair reviewer from a non-virt
> standpoint, if he hopefully has the time to weight in.

I spent an hour with Hugh at Google this summer, and he (like you)
expressed some dislike of the ABI/API and the hooks but he has since
told both me and Andrew he doesn't have time to pursue this.

Others in Google have shown vague interest in tmem for cgroups but
I've been too busy myself to even think about that.

> However keep in mind if we'd see something that can allow KVM to run
> even faster, we'd be quite silly in not taking advantage of it too, to
> beat our own SPECvirt record. The whole design idea of KVM (unlike
> Xen) is to reuse the kernel improvements as much as possible so when
> the guest runs faster the hypervisor also runs faster with the exact
> same code. Problem a vmexit doing a bounce buffer every 4k doesn't mix
> well into SPECvirt in my view and that probably is what has kept us
> from making any attempt to use tmem API anywhere.

If SPECvirt does any swapping that actually goes to disk (doubtful?),
frontswap will help.

Personally, I think SPECvirt was hand-designed by VMware to favor
their platform, but they were chagrined to find that you and KVM
cleverly re-implemented transparent content-based page sharing
which was the feature for which they were designing SPECvirt.
IOW, SPECvirt is benchmarketing not benchmarking... but I know
that's important too. :-)

Sorry for the topic drift...

Thanks,
Dan
--
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/