From mboxrd@z Thu Jan 1 00:00:00 1970 From: Konrad Rzeszutek Wilk Subject: Re: Serious issues with xenpaging Date: Fri, 7 Mar 2014 10:43:39 -0500 Message-ID: <20140307154339.GA10945@phenom.dumpdata.com> References: <55E78A57290FB64FA0D3CF672F9F3DA211C793@SJCPEX01CL03.citrite.net> <20131231153330.GC20357@phenom.dumpdata.com> <20131231163110.GA34150@deinos.phlegethon.org> <556C4AC0-F10F-4977-8FCD-3129E416B062@gridcentric.ca> <20140103184154.GA29283@phenom.dumpdata.com> <20140103203139.GA2570@phenom.dumpdata.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Content-Disposition: inline In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Andres Lagar-Cavilla Cc: Olaf Hering , Tim Deegan , "xen-devel@lists.xen.org" , andres@lagarcavilla.org, "xen-users@lists.xen.org" , Russell Pavlicek List-Id: xen-devel@lists.xenproject.org On Fri, Jan 03, 2014 at 04:17:43PM -0500, Andres Lagar-Cavilla wrote: > On Jan 3, 2014, at 3:31 PM, Konrad Rzeszutek Wilk wrote: > > > On Fri, Jan 03, 2014 at 02:51:14PM -0500, Andres Lagar-Cavilla wrote: > >> On Jan 3, 2014, at 1:41 PM, Konrad Rzeszutek Wilk wrote: > >> > >>> On Fri, Jan 03, 2014 at 09:49:36AM -0500, Andres Lagar-Cavilla wrote: > >>>> > >>>> On Dec 31, 2013, at 11:31 AM, Tim Deegan wrote: > >>>> > >>>>> At 10:33 -0500 on 31 Dec (1388482410), Konrad Rzeszutek Wilk wrote: > >>>>>> On Mon, Dec 23, 2013 at 06:34:55PM +0000, Russell Pavlicek wrote: > >>>>>>> On Twitter, Florian Heigl sent a out a few messages about issues with xenpaging: > >>>>>>> > >>>>>>> --- > >>>>>>> 19-Dec: Anyone successfully use #xen #xenpaging? docs are at SLES manual, rest is mostly this: http://www.gossamer-threads.com/lists/xen/devel/255798 dead feature or usable? > >>>>>>> > >>>>>>> 22-Dec: @lars_kurth @RCPavlicek Hey guys, I wrote down as much as I could https://piratenpad.de/p/Ik3lOBLniq1L5TEM (since I'm on holiday and not constant online) > >>>>>>> > >>>>>>> 22-Dec: Yay, tested #xen Xenpaging (memory overcommit) > >>>>>>> [x] largely untested > >>>>>>> [x] docs outdated > >>>>>>> [x] syntax+logic changed > >>>>>>> [x] broken > >>>>>>> --- > >>>>>>> > >>>>>>> [I've taken the liberty of removing the colorful expletive from the final post] > >>>>>>> > >>>>>>> Is Florian's assessment correct, or is there somewhere we can point him for help? I'm on vacation this week, but if someone replies to me, I will try to forward the information appropriately. > >>>>>> > >>>>>> The Maintainers file implies otherwise. Let me CC the maintainers. > >>>>> > >>>>> Andres really owns this code, so I'll punt to him for an official > >>>>> answer, but: > >>>> The part actively maintained is the hypervisor support for paging, and the interface. > >>>> > >>>> tools/xenpaging is one way to consume that interface. It seems to have suffered from bitrot. > >>> > >>> What is the other interface? Thanks! > >> > >> Not sure what the question is. There is one interface. What I was referring to, is that tools/xenpaging implements one specific paging policy: victim selection, rate limiting, paging target, all of these are algorithms that entirely define what bang for your money you will get. > >> > > > > Right, but there is other code that uses this interface as well correct? > > Is it available for users ? > > That I know of, Gridcentric's product. It's available as proprietary software for a fee. I am unaware of a sharing user other than Gridcentric. Virtuata was a mem-event user, Gridcentric is, and others have surfaced on the list (Razvan Cocajaru for instance). In the context of http://wiki.xenproject.org/wiki/GSoc_2014#Lazy_restore_using_memory_paging should that be removed then? As the dependency of it would be to first 'un-bitrot' it and that might take more than the original GSoC problem statement describes?? > > Andres >