Re: [Xen-devel] LRU list of domids

[Ian Jackson <ian.jackson@xxxxxxxxxx>]

Durrant, Paul writes ("LRU list of domids"):
>   I've been looking at keeping an LRU list of domids to avoid eager recycling 
> and I have a few questions...
> 
>   Keeping history in a file that is updated by libxl seems ok (and I have 
> coded it up), but there is the question of host reboot... something needs to 
> clear history. There's no 'libxl' init script, so not sure where to do it. An 
> alternative - to avoid the scrubbing issue - would be to keep the history in 
> xenstore, under libxl's top level path. Do you think that would be a 
> reasonable alternative to a file?

I think that would be tolerable, although storing a list of 2^15
2-byte values as a set of 2^15 xenstore nodes is rather flabby and
will make the output of xenstore-ls hard to use.  It might need the
pruning you suggest (see below).

But you might like to consider (i) whether scrubbing the LRU list is
something that tools/helpers/xen-init-dom0 could do - this is normally
indeed called from init scripts at boot time (ii) whether scrubbing
the LRU list on reboot is in fact needed at all.

>   Also, how much history do we keep by default and how tunable do you think 
> it should be? Also, if it needs to be tunable then how should it be tuned? 
> Env variable perhaps?

I was imagining we would keep a complete list of all possible domids,
in an order.  domids go up to 2^15 so fit in two bytes.  2^15 x 2
bytes = 65536 bytes, which is a trivial amount to store and process if
handled appropriately.  It's not brilliant in xenstore but it would be
fine for a file in a tmpfs like [/var]/run.

We need to control not only tuning, but also the default allocation
policy.  I suggest that we record the allocation policy somewhere near
the list of domids.  It could be configured at boot time by some
utility like xen-init-dom0.

Environment variables are not brilliant for this kind of thing because
they may not be set in all context, or may vary.  They are a nuisance
to arrange to be set everywhere.  That makes it more necessary to
devise pleasant behaviours for the corner cases where the tuning
varies from operation to operation.

Thanks,
Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel