On Thu, 2016-08-11 at 16:51 +0100, Andrew Cooper wrote:
> On 11/08/16 15:59, Dario Faggioli wrote:
> >
> > Which, I think needs at least this hunk (from 6b53bb4ab3c9 "sched:
> > better handle (not) inserting idle vCPUs in runqueues"):
> >
> > diff --git a/xen/common/schedule.c b/xen/common/sched
On 11/08/16 15:59, Dario Faggioli wrote:
> On Fri, 2016-08-05 at 07:24 -0600, Jan Beulich wrote:
>> I'd really like to have those backported, but I have to ask one
>> of you to identify which prereq-s are needed on 4.6 and 4.5
>> (I'll revert them from 4.5 right away, but I'll wait for an osstest
>
On Fri, 2016-08-05 at 07:24 -0600, Jan Beulich wrote:
> I'd really like to have those backported, but I have to ask one
> of you to identify which prereq-s are needed on 4.6 and 4.5
> (I'll revert them from 4.5 right away, but I'll wait for an osstest
> flight to confirm the same issue exists on 4.
>>> On 05.08.16 at 16:09, wrote:
> On Fri, 2016-08-05 at 07:24 -0600, Jan Beulich wrote:
>> > > > On 01.08.16 at 14:32, wrote:
>> > On Mon, 2016-08-01 at 04:40 -0600, Jan Beulich wrote:
>> > > > > > On 15.07.16 at 20:02, wrote:
>> > > > Signed-off-by: George Dunlap
>> > > Should this and patch
On Fri, 2016-08-05 at 07:24 -0600, Jan Beulich wrote:
> > > > On 01.08.16 at 14:32, wrote:
> > On Mon, 2016-08-01 at 04:40 -0600, Jan Beulich wrote:
> > > > > > On 15.07.16 at 20:02, wrote:
> > > > Signed-off-by: George Dunlap
> > > Should this and patch 3 be backported?
> > >
> > Yes, I think
>>> On 01.08.16 at 14:32, wrote:
> On Mon, 2016-08-01 at 04:40 -0600, Jan Beulich wrote:
>> > > > On 15.07.16 at 20:02, wrote:
>> >
>> > To solve this, when inserting a vcpu, always call the per-scheduler
>> > "pick" function to revise the initial placement. This will
>> > automatically take al
On Mon, 2016-08-01 at 04:40 -0600, Jan Beulich wrote:
> > > > On 15.07.16 at 20:02, wrote:
> >
> > To solve this, when inserting a vcpu, always call the per-scheduler
> > "pick" function to revise the initial placement. This will
> > automatically take all knowledge the scheduler has into accoun
>>> On 15.07.16 at 20:02, wrote:
> The generic domain creation logic in
> xen/common/domctl.c:default_vcpu0_location() attempts to try to do
> initial placement load-balancing by placing vcpu 0 on the least-busy
> non-primary hyperthread available. Unfortunately, the logic can end
> up picking a
On Mon, 2016-07-25 at 12:17 +0100, George Dunlap wrote:
> On 18/07/16 11:28, Dario Faggioli wrote:
> >
> > On Fri, 2016-07-15 at 19:02 +0100, George Dunlap wrote:
> > >
> > > Signed-off-by: George Dunlap
> > > ---
> > > CC: Dario Faggioli
> > > CC: Anshul Makkar
> > > CC: Meng Xu
> > > CC: Ja
On Mon, Jul 25, 2016 at 7:17 AM, George Dunlap wrote:
> On 18/07/16 11:28, Dario Faggioli wrote:
>> On Fri, 2016-07-15 at 19:02 +0100, George Dunlap wrote:
>>> The generic domain creation logic in
>>> xen/common/domctl.c:default_vcpu0_location() attempts to try to do
>>> initial placement load-bal
On Fri, Jul 15, 2016 at 2:02 PM, George Dunlap wrote:
>
> The generic domain creation logic in
> xen/common/domctl.c:default_vcpu0_location() attempts to try to do
> initial placement load-balancing by placing vcpu 0 on the least-busy
> non-primary hyperthread available. Unfortunately, the logic
On 18/07/16 11:28, Dario Faggioli wrote:
> On Fri, 2016-07-15 at 19:02 +0100, George Dunlap wrote:
>> The generic domain creation logic in
>> xen/common/domctl.c:default_vcpu0_location() attempts to try to do
>> initial placement load-balancing by placing vcpu 0 on the least-busy
>> non-primary hyp
On Mon, 2016-07-18 at 22:36 +0100, Andrew Cooper wrote:
> On 18/07/2016 19:55, Dario Faggioli wrote:
> >
> > On Mon, 2016-07-18 at 19:10 +0100, Andrew Cooper wrote:
> > >
> > > On 16/07/16 15:12, Dario Faggioli wrote:
> > > >
> > > > On Fri, 2016-07-15 at 19:07 +0100, Andrew Cooper wrote:
> > >
On 18/07/2016 19:55, Dario Faggioli wrote:
> On Mon, 2016-07-18 at 19:10 +0100, Andrew Cooper wrote:
>> On 16/07/16 15:12, Dario Faggioli wrote:
>>> On Fri, 2016-07-15 at 19:07 +0100, Andrew Cooper wrote:
>>> So you have to always keep IRQ enabled, for all scheduling
>>> operations,
>>> which is ok
On Mon, 2016-07-18 at 19:10 +0100, Andrew Cooper wrote:
> On 16/07/16 15:12, Dario Faggioli wrote:
> > On Fri, 2016-07-15 at 19:07 +0100, Andrew Cooper wrote:
> > So you have to always keep IRQ enabled, for all scheduling
> > operations,
> > which is ok for _almost_ all of them, with the only excep
On 16/07/16 15:12, Dario Faggioli wrote:
> On Fri, 2016-07-15 at 19:07 +0100, Andrew Cooper wrote:
>
>> None of the scheduler-accounting functions should be disabling
>> interrupts.
>>
> They don't. But you can't keep irq disabled for some operations and
> enabled for others, on the same lock (beca
On Fri, 2016-07-15 at 19:02 +0100, George Dunlap wrote:
> The generic domain creation logic in
> xen/common/domctl.c:default_vcpu0_location() attempts to try to do
> initial placement load-balancing by placing vcpu 0 on the least-busy
> non-primary hyperthread available. Unfortunately, the logic c
On Fri, 2016-07-15 at 19:07 +0100, Andrew Cooper wrote:
> On 15/07/16 19:02, George Dunlap wrote:
> >
> > diff --git a/xen/common/sched_credit2.c
> > b/xen/common/sched_credit2.c
> > index 3b9aa27..5a04985 100644
> > --- a/xen/common/sched_credit2.c
> > +++ b/xen/common/sched_credit2.c
> > @@ -162
On 15/07/16 19:02, George Dunlap wrote:
> diff --git a/xen/common/sched_credit2.c b/xen/common/sched_credit2.c
> index 3b9aa27..5a04985 100644
> --- a/xen/common/sched_credit2.c
> +++ b/xen/common/sched_credit2.c
> @@ -1620,15 +1620,23 @@ csched2_vcpu_insert(const struct scheduler *ops,
> struct v
The generic domain creation logic in
xen/common/domctl.c:default_vcpu0_location() attempts to try to do
initial placement load-balancing by placing vcpu 0 on the least-busy
non-primary hyperthread available. Unfortunately, the logic can end
up picking a pcpu that's not in the online mask. When th
20 matches
Mail list logo
