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

> > +# 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

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

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,
<<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)

Attachment: signature.asc
Description: This is a digitally signed message part

Xen-devel mailing list

Reply via email to