On Thu, 2016-10-13 at 12:47 +0100, Andrew Cooper wrote: > On 13/10/16 12:02, Dario Faggioli wrote: > > > > diff --git a/docs/features/credit.pandoc > > b/docs/features/credit.pandoc > > new file mode 100644 > > index 0000000..fed0da2 > > --- /dev/null > > +++ b/docs/features/credit.pandoc > > Simply "Credit" as a top level feature isn't very descriptive. Can > you > see about working scheduler somewhere into the name? > Yep, I wasn't sure whether or not to do that. Re-thinking things, I agree that'd be better. I'll do.
> > @@ -0,0 +1,99 @@ > > +% Credit > > +% Revision 1 > > + > > +\clearpage > > + > > +# Basics > > +---------------- ----------------------------------------------- > > ----- > > + Status: e.g. **Supported** > > + > > +Architecture(s): e.g. x86, arm > > + > > + Component: e.g. Hypervisor > > +---------------- ----------------------------------------------- > > ----- > > You should drop the e.g.'s. > Which I was sure I'd have done... sorry. > In cases like this where it really is just > a software algorithm, I would suggest setting the architecture to > all, > or omitting the line entirely. > Omitting the line is what I also was considering myself. Again, will do. > > +# Overview > > + > > +Credit (also known as Credit1) is the default virtual CPU (vCPU) > > scheduler > > +of the Xen hypervisor. The job of an hypervisor's scheduler is to > > decide, > > +among all the various vCPUs of the various virtual machines, which > > ones > > +should execute on the host's physical CPUs (pCPUs), at any given > > point in > > +time. > > A lot of this is generic to all schedulers. > Not really. Well, sure some is, but, at the end, this period is pretty much the only one that is present, identical to itself, in all the three documents (and I certainly can see about shortening or removing it, if we don't want that). And in fact, the rest... > I wonder whether it might be better to have a schedulers meta-feature > doc which deals with the common scheduler parts, including > interactions > on the Xen command line, xl, etc. > ...may look similar, but they're subtle differences spread around. And the more subtle those differences, the higher the amount of cross- referencing between different documents would be, making it more difficult to read and understand what the situation is for one specific scheduler. xl interface is a good example: sub-commands are very similar, but then the scheduling parameters are different for each scheduler. The way in which you create a cpupool is the same (modulo the name=""), but doesn't necessarily have to be, e.g., if we start allowing specifing some of the global parameters of the scheduler on the command line (e.g., "create a Credit cpupool, but with timeslice=10"). Not possible right now, but doable, and even convenient (I've already have plans for that :-P). So, FWIW, I would stick with different documents. > > +Once the system is live, for creating a cpupool with Credit as its > > +scheduler, either compile a cpupool configuration file, as > > described > > +in `docs/man/xlcpupool.cfg.pod.5` (and as exemplified in > > +`tools/examples/cpupool`), or use just `xl` directly: > > I should see about ensuring that cross-references work with the > HTML-generated versions of these docs. You might be able to get away > with just putting in a plain hyperlink here. > I thought about that, but then ended up following suit from your docs/feature/migration.pandoc. I'll turn this in links if that's what you think is best. Personally, I 's say it makes the _text_ document a bit less readable, but I guess the version we care about is the _HTML_ one? Anyway, I'm basically ok with anything. :-) Thanks and Regards, Dario -- <<This happens because I choose it to happen!>> (Raistlin Majere) ----------------------------------------------------------------- Dario Faggioli, Ph.D, http://about.me/dario.faggioli Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)
signature.asc
Description: This is a digitally signed message part
_______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
