* tmem ephemeral page discarding
@ 2013-06-02 4:06 James Harper
2013-06-03 12:21 ` Konrad Rzeszutek Wilk
0 siblings, 1 reply; 6+ messages in thread
From: James Harper @ 2013-06-02 4:06 UTC (permalink / raw)
To: xen-devel@lists.xen.org
How does Xen manage ephemeral pages? Is there a way to manage the priority of pages in the ephemeral store? In my use case, I would prefer that an old page was automatically discarded to make room for a new page, and that pages that have been retrieved already are more likely to be discarded than a page that has not yet been retrieved.
Thanks
James
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: tmem ephemeral page discarding
2013-06-02 4:06 tmem ephemeral page discarding James Harper
@ 2013-06-03 12:21 ` Konrad Rzeszutek Wilk
2013-06-03 16:28 ` Dan Magenheimer
0 siblings, 1 reply; 6+ messages in thread
From: Konrad Rzeszutek Wilk @ 2013-06-03 12:21 UTC (permalink / raw)
To: James Harper; +Cc: dan.magenheimer, xen-devel@lists.xen.org
On Sun, Jun 02, 2013 at 04:06:18AM +0000, James Harper wrote:
> How does Xen manage ephemeral pages? Is there a way to manage the priority of pages in the ephemeral store? In my use case, I would prefer that an old page was automatically discarded to make room for a new page, and that pages that have been retrieved already are more likely to be discarded than a page that has not yet been retrieved.
>
In other words an LRU system with bounds. Right now the bounds are the amount of memory available and
when Xen needs more memory the bounds gets decreased - which will discard the least used ephermeal pages.
There is a tmem subop to actually set the cap (TMEMC_SET_CAP), which sets the cap value. However
I am not seeing in the code anybody using it. Hmmm
> Thanks
>
> James
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
>
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: tmem ephemeral page discarding
2013-06-03 12:21 ` Konrad Rzeszutek Wilk
@ 2013-06-03 16:28 ` Dan Magenheimer
2013-06-04 1:42 ` James Harper
0 siblings, 1 reply; 6+ messages in thread
From: Dan Magenheimer @ 2013-06-03 16:28 UTC (permalink / raw)
To: Konrad Wilk, James Harper; +Cc: xen-devel
> From: Konrad Rzeszutek Wilk
> Sent: Monday, June 03, 2013 6:22 AM
> To: James Harper
> Cc: xen-devel@lists.xen.org; Dan Magenheimer
> Subject: Re: [Xen-devel] tmem ephemeral page discarding
>
> On Sun, Jun 02, 2013 at 04:06:18AM +0000, James Harper wrote:
> > How does Xen manage ephemeral pages? Is there a way to manage the priority of pages in the ephemeral
> store? In my use case, I would prefer that an old page was automatically discarded to make room for a
> new page, and that pages that have been retrieved already are more likely to be discarded than a page
> that has not yet been retrieved.
>
> In other words an LRU system with bounds. Right now the bounds are the amount of memory available and
> when Xen needs more memory the bounds gets decreased - which will discard the least used ephermeal
> pages.
It sounds like Xen tmem matches your use case. Ephemeral pages that have been retrieved
are actually removed from tmem, i.e. ephemeral gets are "destructive", i.e. an ephemeral
get implies a flush. (Note: This isn't true for shared ephemeral pages, but I don't
think you care about clustered filesystems so ignore that case for now.)
And ephemeral pages (as Konrad replied) are kept in a LRU queue across all
(tmem-aware) guests and the LRU ephemeral page across all guests is
discarded. Or if a weight limit is exceeded, the LRU ephemeral
page belonging to the current guest is discarded.
> There is a tmem subop to actually set the cap (TMEMC_SET_CAP), which sets the cap value. However
> I am not seeing in the code anybody using it. Hmmm
See discussion in "Weights and caps" in docs/misc/tmem-internals.html (or on the web at
https://oss.oracle.com/projects/tmem/dist/documentation/internals/xen4-internals-v01.html )
The current cap non-implementation is per-guest, but I never found
a good use model for it so never implemented it, outside of the
toolstack control interface. Caps exist only because "weights+caps"
make sense for a CPU scheduler and I thought both might make sense
also for a "memory scheduler".
If you have a use model for it (or a use model for across-all-guests
cap), it shouldn't be hard to implement.
Hope that helps!
Dan
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: tmem ephemeral page discarding
2013-06-03 16:28 ` Dan Magenheimer
@ 2013-06-04 1:42 ` James Harper
2013-06-04 2:50 ` Dan Magenheimer
0 siblings, 1 reply; 6+ messages in thread
From: James Harper @ 2013-06-04 1:42 UTC (permalink / raw)
To: Dan Magenheimer, Konrad Wilk; +Cc: xen-devel@lists.xen.org
>
> And ephemeral pages (as Konrad replied) are kept in a LRU queue across all
> (tmem-aware) guests and the LRU ephemeral page across all guests is
> discarded. Or if a weight limit is exceeded, the LRU ephemeral
> page belonging to the current guest is discarded.
>
Yep that sounds about perfect.
I can't seem to get it working under 64 bit windows at the moment... keeps returning -ENOSYS and I'm wondering if windows and linux differ in their structure alignment or something. I remember this being a problem with vbd.
Btw, the choice of 'new' as a struct name in the tmem struct isn't necessarily wise... it might never come up but 'new' is a reserved word in c++.
James
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: tmem ephemeral page discarding
2013-06-04 1:42 ` James Harper
@ 2013-06-04 2:50 ` Dan Magenheimer
2013-06-04 3:06 ` James Harper
0 siblings, 1 reply; 6+ messages in thread
From: Dan Magenheimer @ 2013-06-04 2:50 UTC (permalink / raw)
To: James Harper, Konrad Wilk; +Cc: xen-devel
> From: James Harper [mailto:james.harper@bendigoit.com.au]
> Sent: Monday, June 03, 2013 7:42 PM
> To: Dan Magenheimer; Konrad Wilk
> Cc: xen-devel@lists.xen.org
> Subject: RE: [Xen-devel] tmem ephemeral page discarding
>
> >
> > And ephemeral pages (as Konrad replied) are kept in a LRU queue across all
> > (tmem-aware) guests and the LRU ephemeral page across all guests is
> > discarded. Or if a weight limit is exceeded, the LRU ephemeral
> > page belonging to the current guest is discarded.
> >
>
> Yep that sounds about perfect.
>
> I can't seem to get it working under 64 bit windows at the moment... keeps returning -ENOSYS and I'm
> wondering if windows and linux differ in their structure alignment or something. I remember this being
> a problem with vbd.
Any chance you've not enabled it? Tmem is disabled by default
and you need to provide "tmem" as a boot parameter to xen to
enable it. Tmem calls from a guest will fail if it is
disabled.
> Btw, the choice of 'new' as a struct name in the tmem struct isn't necessarily wise... it might never
> come up but 'new' is a reserved word in c++.
Hmmm... Where are you seeing it? I do see it in the tmem
code as a local parameter ("new" is used in code in other
places in Xen as well), but not in a public structure definition.
Thanks,
Dan
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: tmem ephemeral page discarding
2013-06-04 2:50 ` Dan Magenheimer
@ 2013-06-04 3:06 ` James Harper
0 siblings, 0 replies; 6+ messages in thread
From: James Harper @ 2013-06-04 3:06 UTC (permalink / raw)
To: Dan Magenheimer, Konrad Wilk; +Cc: xen-devel@lists.xen.org
> > I can't seem to get it working under 64 bit windows at the moment... keeps
> > returning -ENOSYS and I'm
> > wondering if windows and linux differ in their structure alignment or
> > something. I remember this being
> > a problem with vbd.
>
> Any chance you've not enabled it? Tmem is disabled by default
> and you need to provide "tmem" as a boot parameter to xen to
> enable it. Tmem calls from a guest will fail if it is
> disabled.
I botched a cut&paste when adding the new x64 hypercall to GPLPV. Oops. All good now
> > Btw, the choice of 'new' as a struct name in the tmem struct isn't
> necessarily wise... it might never
> > come up but 'new' is a reserved word in c++.
>
> Hmmm... Where are you seeing it? I do see it in the tmem
> code as a local parameter ("new" is used in code in other
> places in Xen as well), but not in a public structure definition.
>
I was looking at very old source and now I see it was resolved over 2 years ago http://xenbits.xen.org/hg/xen-unstable.hg/rev/0353037c6b95
Thanks
James
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2013-06-04 3:06 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2013-06-02 4:06 tmem ephemeral page discarding James Harper
2013-06-03 12:21 ` Konrad Rzeszutek Wilk
2013-06-03 16:28 ` Dan Magenheimer
2013-06-04 1:42 ` James Harper
2013-06-04 2:50 ` Dan Magenheimer
2013-06-04 3:06 ` James Harper
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.