Xen devel - May 2007 - [PATCH] tunable time slice for credit scheduler

Hi,

This patch intends to add tunablity for time slice on credit scheduler.
Each domain can change time slice. 

for example, 
xm sched-credit -d 0 -s 20
(unit is msec)

Signed-off-by: Atsushi SAKAI <sakaia@jp.fujitsu.com>

c.f.
1)libxc(pyxc) forgets help message for cap.
I add it on tools/python/xen/lowlevel/xc/xc.c

2)time slice can set from 1 to 100(msec).
I have see VNC connection timeout problem for many domain on one CPU.
For this reason, it can set time slice from 1 to 100 msec.
Of course, default value is 30msec.


Thanks
Atsushi SAKAI



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

¾
hi
I am confused about the differences betwoon xen in x86_32 and x86_64
in x86_32,Ring 1 for guest OS, ring3 for user-space, Xen lives in top 
64MB of linear addr space, Segmentation used to protect Xen as switching 
page tables too slow on standard x86, Hypercalls jump to Xen in ring 0, 
Guest OS with ‘fast trap’ handler could direct user-space to guest OS 
system calls, is it right?
while in x86_64 ,both guestos and userapplications seem to run in ring3, 
and what about other thing memtioned above for x86_64? such as the 
memory mapping for xen and guestos kernel and applications , system call 
fast trap handling


I am confused about it
could you help me
Thanks in advance

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

The sched_credit.c part of this patch looks good to me (except for
the coding style issues). Before adding per-domain tunable time
slices though, shouldn''t we make the global time slice tunable?


On May 17, 2007, at 10:25, Atsushi SAKAI wrote:
> Hi,
>
> This patch intends to add tunablity for time slice on credit scheduler.
> Each domain can change time slice.
>
> for example,
> xm sched-credit -d 0 -s 20
> (unit is msec)
>
> Signed-off-by: Atsushi SAKAI <sakaia@jp.fujitsu.com>
>
> c.f.
> 1)libxc(pyxc) forgets help message for cap.
> I add it on tools/python/xen/lowlevel/xc/xc.c
>
> 2)time slice can set from 1 to 100(msec).
> I have see VNC connection timeout problem for many domain on one CPU.
> For this reason, it can set time slice from 1 to 100 msec.
> Of course, default value is 30msec.
>
>
> Thanks
> Atsushi SAKAI
>
> <tune_timeslice.patch>_______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

I''m not sure that extra parameters are what the scheduler really needs.
Tuning for better performance ''out of the box'' would be more
useful. Under
what circumstances were you seeing VNC connection timeouts? If it''s an
extreme overload situation then that can likely be detected and dealt with
by automatic time-slice adjustment. I can''t see a time-slice option
being
used sensibly in many scenarios.

 -- Keir

On 27/6/07 13:08, "Emmanuel Ackaouy" <ackaouy@gmail.com> wrote:
> The sched_credit.c part of this patch looks good to me (except for
> the coding style issues). Before adding per-domain tunable time
> slices though, shouldn''t we make the global time slice tunable?
> 
> 
> On May 17, 2007, at 10:25, Atsushi SAKAI wrote:
> 
>> Hi,
>> 
>> This patch intends to add tunablity for time slice on credit scheduler.
>> Each domain can change time slice.
>> 
>> for example,
>> xm sched-credit -d 0 -s 20
>> (unit is msec)
>> 
>> Signed-off-by: Atsushi SAKAI <sakaia@jp.fujitsu.com>
>> 
>> c.f.
>> 1)libxc(pyxc) forgets help message for cap.
>> I add it on tools/python/xen/lowlevel/xc/xc.c
>> 
>> 2)time slice can set from 1 to 100(msec).
>> I have see VNC connection timeout problem for many domain on one CPU.
>> For this reason, it can set time slice from 1 to 100 msec.
>> Of course, default value is 30msec.
>> 
>> 
>> Thanks
>> Atsushi SAKAI
>> 
>>
<tune_timeslice.patch>_______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xensource.com
>> http://lists.xensource.com/xen-devel
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Hi, Keir and Emmanuel

 Thanks for reviewing.
I am very happy to get a comment on this.

Primary motivation of this patch is 
Network benchmark(Web server throughput) at Xen.
(Which is presented on XenSummit 2007 Spring)

In this comparison, 
network through put is not good if you use credit scheduler
http://www.xensource.com/files/xensummit_4/3schedulers-xen-summit_Cherkosova.pdf

In this presentation, SEDF and BVT selects the best parameter before 
comparison.(p.9)
On the other hand, Credit Scheduler does not have such kind of 
tunable paramter.
I think the comparison is not fare.
This patch adds this kind of parameter for fare comparison.

And I think time slice should be differenciated by 
Dom0, DriverDomain and Others.
So I make this patch defining each domain timeslice. 
But as a first step, global time slice is a good idea.


Anyway, this is not related to VNC issue.

Thanks
Atsushi SAKAI


Keir Fraser <keir@xensource.com> wrote:
> I''m not sure that extra parameters are what the scheduler really
needs.
> Tuning for better performance ''out of the box'' would be
more useful. Under
> what circumstances were you seeing VNC connection timeouts? If
it''s an
> extreme overload situation then that can likely be detected and dealt with
> by automatic time-slice adjustment. I can''t see a time-slice
option being
> used sensibly in many scenarios.
> 
>  -- Keir
> 
> On 27/6/07 13:08, "Emmanuel Ackaouy" <ackaouy@gmail.com>
wrote:
> 
> > The sched_credit.c part of this patch looks good to me (except for
> > the coding style issues). Before adding per-domain tunable time
> > slices though, shouldn''t we make the global time slice
tunable?
> > 
> > 
> > On May 17, 2007, at 10:25, Atsushi SAKAI wrote:
> > 
> >> Hi,
> >> 
> >> This patch intends to add tunablity for time slice on credit
scheduler.
> >> Each domain can change time slice.
> >> 
> >> for example,
> >> xm sched-credit -d 0 -s 20
> >> (unit is msec)
> >> 
> >> Signed-off-by: Atsushi SAKAI <sakaia@jp.fujitsu.com>
> >> 
> >> c.f.
> >> 1)libxc(pyxc) forgets help message for cap.
> >> I add it on tools/python/xen/lowlevel/xc/xc.c
> >> 
> >> 2)time slice can set from 1 to 100(msec).
> >> I have see VNC connection timeout problem for many domain on one
CPU.
> >> For this reason, it can set time slice from 1 to 100 msec.
> >> Of course, default value is 30msec.
> >> 
> >> 
> >> Thanks
> >> Atsushi SAKAI
> >> 
> >>
<tune_timeslice.patch>_______________________________________________
> >> Xen-devel mailing list
> >> Xen-devel@lists.xensource.com
> >> http://lists.xensource.com/xen-devel
> > 
> > 
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@lists.xensource.com
> > http://lists.xensource.com/xen-devel
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

> I am confused about the differences betwoon xen in x86_32 and x86_64
> in x86_32,Ring 1 for guest OS, ring3 for user-space, Xen lives in top
> 64MB of linear addr space, Segmentation used to protect Xen as switching
> page tables too slow on standard x86, Hypercalls jump to Xen in ring 0,
> Guest OS with ‘fast trap’ handler could direct user-space to guest OS
> system calls, is it right?
Yes, that''s right.
> while in x86_64 ,both guestos and userapplications seem to run in ring3,
> and what about other thing memtioned above for x86_64? such as the
> memory mapping for xen and guestos kernel and applications , system call
> fast trap handling
Xen still lives at the top of the address space; I''m not sure how much
it
reserves for itself.  The guest kernel (when mapped) lives below Xen.  Guest 
userspace lives below that.

When running in guest usermode only the guest userspace and Xen are mapped 
into memory.  Xen is protected from guest userspace using the supervisor 
protection bit in the pagetables.

AFAIK, all system calls must bounce through Xen.  I don''t think
it''s possible
for OSes to take syscalls directly anymore.  This is because Xen has to map 
the guest kernel''s pages into memory (by hooking an extra subtree into
the
current pagetable).  Xen then kicks the guest kernel into action; the kernel 
can directly access userspace pages since they are still mapped.  Xen is 
protected from the guest kernel by the supervisor protection bit in the 
pagetables.

When the kernel finishes its work it has to execute a hypercall to instruct 
Xen to transfer control back to userspace.  Xen has to flush the TLB at this 
point to remove the kernel mappings; otherwise it could be possible for the 
guest''s userspace to interfere with the kernel''s memory.

I believe the "global" bit is set on guest userspace pagetable
entries, which
means that the userspace mappings are not flushed at this point (performance 
optimisation).  Xen can still flush these mappings with a "global
flush" if a
switch of application running or of domain occurs.
> I am confused about it
> could you help me
> Thanks in advance
Hope that helps.

Cheers,
Mark

-- 
Dave: Just a question. What use is a unicyle with no seat?  And no pedals!
Mark: To answer a question with a question: What use is a skateboard?
Dave: Skateboards have wheels.
Mark: My wheel has a wheel!

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel