On Mar 7, 2014, at 10:43 AM, Konrad Rzeszutek Wilk
<konrad.wilk@oracle.com> wrote:
> 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
<konrad.wilk@oracle.com> 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
<konrad.wilk@oracle.com> 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
<tim@xen.org> 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<https://twitter.com/search?q=%23xen&src=hash>
#xenpaging<https://twitter.com/search?q=%23xenpaging&src=hash>? docs
are at SLES manual, rest is mostly this:
http://www.gossamer-threads.com/lists/xen/devel/255798<http://t.co/P36VdL84Et>
dead feature or usable?
>>>>>>>>>
>>>>>>>>> 22-Dec:
@lars_kurth<https://twitter.com/lars_kurth>
@RCPavlicek<https://twitter.com/RCPavlicek> Hey guys, I wrote down as much
as I could https://piratenpad.de/p/Ik3lOBLniq1L5TEM
<https://t.co/e5LQCUD9d0> (since I'm on holiday and not constant
online)
>>>>>>>>>
>>>>>>>>> 22-Dec: Yay, tested
#xen<https://twitter.com/search?q=%23xen&src=hash> 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??
My take is that whatever xenpaging un-bitroting may be needed, it will be
completely independent of the GSOC project. One objective of this GSOC project
is to show another way to put men paging to use. I envision this project to be
entirely user-space dom0 code, and to not rely on any existing tools/xenpaging
code (ok, maybe refactor the set up of the paging event ring).
Does that make sense?
Thanks
Andres
>
>>
>> Andres
>>