Messages in this thread | | | Date | Thu, 3 Nov 2011 15:29:34 -0700 (PDT) | From | Dan Magenheimer <> | Subject | RE: [GIT PULL] mm: frontswap (for 3.2 window) |
| |
> From: Andrea Arcangeli [mailto:aarcange@redhat.com] > Subject: Re: [GIT PULL] mm: frontswap (for 3.2 window)
Hi Andrea --
Sorry for the delayed response... and for continuing this thread further, but I want to ensure I answer your points.
First, did you see my reply to Rik that suggested a design as to how KVM could do batching with no change to the hooks or frontswap_ops API? (Basically a guest-side cache and add a batching op to the KVM-tmem ABI.) I think it resolves your last remaining concern (too many vmexits), so am eager to see if you agree.
> Like somebody already pointed out (and I agree) it'd be nice to get > the patches posted to the mailing list (with git send-emails/hg
Frontswap v10 https://lkml.org/lkml/2011/9/15/367 as last posted to linux-mm has identical code to the git commits... in response to Konrad and Kame, the commit-set was slightly reorganized and extended from 6 commits to 8, but absolutely no code differences. Since no code was changed between v10 and v11, I didn't repost v11 to linux-mm.
Note, every version of frontswap was posted to linux-mm and cc'ed to Andrew, Hugh, Nick and Rik and I was very diligent in responding to all comments... Wish I would have cc'ed you all along as this has been a great discussion.
> email/quilt) and get them merged into -mm first.
Sorry, I'm still a newbie on this process, but just to clarify, "into -mm" means Andrew merges the patches, right? Andrew said in the first snippet of https://lkml.org/lkml/2011/11/1/317 that linux-next is fine, so I'm not sure whether to follow your advice or not.
> Thanks. So this overall sounds fairly positive (or at least better > than neutral) to me.
Excellent!
> On my side I hope it get improved over time to get the best out of > it. I've not been hugely impressed so far because at this point in > time it doesn't seem a vast improvement in runtime behavior compared > to what zram could provide, like Rik said there's no iov/SG/vectored > input to tmem_put (which I'd find more intuitive renamed to > tmem_store), like Avi said ramster is synchronous and not good having > to wait a long time. But if we can make these plugins stackable and we > can put a storage backend at the end we could do > storage+zcache+frontswap.
This thread has been so long, I don't even remember what I've replied to who, so just to clarify on these several points, in case you didn't see these elsewhere in the thread:
- Nitin Gupta, author of zram, thinks zcache is an improvement over zram because it is more flexible/dynamic - KVM can do batching fairly easily with no changes to the hooks or frontswap_ops with the design I recently proposed - RAMster is synchronous, but the requirement is _only_ on the "local" put... once the data is "in tmem", asynchronous threads can do other things with it (like RAMster moving the pages to a tmem pool on a remote system) - the plugins as they exist today (Xen, zcache) aren't stackable, but the frontswap_ops registration already handles stacking, so it is certainly a good future enhancement... RAMster already does "stacking", but by incorporating a copy of the zcache code. (I think that's just a code organization issue that can be resolved if/when RAMster goes into staging.)
With these in mind, I hope you will now be even a "lot more happy now" with frontswap and MUCH better than neutral. :-) :-)
Dan
| |