[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] LRU list of domids
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
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |