Quantcast
Channel: lkml.org : Vaidyanathan Srinivasan

Re: [RFC PATCH 0/8][Sorted-buddy] mm: Linux VM Infrastructure to s ...

$
0
0
Vaidyanathan Srinivasan writes: (Summary) This optimization can be actually be delayed in the free fast path and completely avoided if our memory is full and we are doing direct reclaim during allocations.

[...]


This is required to actually evaluate power saving benefit once we have candidate implementations in the VM.

At this point we want to look at overheads of having region infrastructure in VM and how does that trade off in terms of requirements that we can meet.

The first goal is to have memory allocations fill as few regions as possible when system's memory usage is significantly lower.

Re: [RFC PATCH 4/5] cpuidle/ppc: CPU goes tickless if there are no ...

$
0
0
Vaidyanathan Srinivasan writes: (Summary) The cost of keeping the periodic tick ON on the broadcast CPU in minimal (but not zero) since we would not allow that CPU to enter any deep idle states even if there were no periodic timers queued.

[...]


This will be an improvement and the idea we have is to have a hierarchical method of finding a waking CPU within core/socket/node in order to find a better fit and ultimately send IPI to wakeup a broadcast CPU only if there is no other fit.

Re: [RFC PATCH 4/5] cpuidle/ppc: CPU goes tickless if there are no ...

$
0
0
Vaidyanathan Srinivasan writes: (Summary) We do pay a power penalty by waking up few jiffies earlier which we can mitigate by reevaluating the situation and queueing a fine grain timer to the right jiffy on the bc_cpu if such a situation arises.

The point is a new wakeup request will *ask* for a wakeup later than the coarse grain period. So the bc_cpu can wakeup at the coarse time period and reprogram its timer to the right jiffy.

--Vaidy

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/


[PATCH 0/3] sched: Fixes for task placement in SMT threads

$
0
0
Vaidyanathan Srinivasan writes: (Summary) Hi,

The following series fixes scheduler loadbalancing issues where we are missing opportunity to place tasks in SMT threads optimally especially on a POWER7 system.

PATCH 1/3, Fixes the scenario where load balancing fails to move tasks away from the cpus in a domain which has SHARE_PKG_RESOURCES set even under the presence of idle cpus in other domains.

PATCH 2/3, ensures lower order SMT threads are used for the SD_ASYM_PACKING load balancing case.

PATCH 3/3, tries to fix the problem that is explained in its changelog.

[PATCH 1/3] sched: Fix nohz_kick_needed to consider the nr_busy of ...

$
0
0
Vaidyanathan Srinivasan writes: (Summary) With the current implementation of nohz_kick_needed(), at this domain(sd), the nr_busy will be 1 always since it returns this parameter for sd->groups which encompasses a single thread, while we want this parameter for sd->parent->groups which will rightly point to the number of busy threads in the core.

This patch also ensures that the order of check for SD_SHARE_PKG_RESOURCE comes before the check for ASYM_PACKING. + + if (sd_parent) { + sg = sd_parent->groups;

[PATCH 2/3] sched: Fix asymmetric scheduling for POWER7

$
0
0
Vaidyanathan Srinivasan writes: (Summary) The goal for the load balancer is to move tasks to lower order idle SMT threads within a core on a POWER7 system.

In nohz_kick_needed(), we intend to check if our sched domain (core) is completely busy or we have idle cpu.

The following check for SD_ASYM_PACKING:

(cpumask_first_and(nohz.idle_cpus_mask, sched_domain_span(sd)) < cpu)
already covers the case of checking if the domain has an idle cpu, because cpumask_first_and() will not yield any set bits if this domain has no idle cpu.

Hence, nr_busy check against group weight can be removed.

[PATCH 3/3] sched: Aggressive balance in domains whose groups shar ...

$
0
0
Vaidyanathan Srinivasan writes: (Summary) If the load cannot be moved from the busiest cpu to dst_cpu due to either tsk_cpus_allowed mask or cache hot tasks, then the dst_cpu is changed to be another idle cpu within the dst->grpmask. The next busiest group is found and the above steps are repeated.

However if the cpus in the group share package resources, then when a load movement from the busiest cpu in this group fails as above, instead of finding the next busiest group to move load from, find the next busiest cpu *within the same group* from which to move load away.

Re: [PATCH] cpuidle: powernv/pseries: Decrease the snooze residency

$
0
0
Vaidyanathan Srinivasan writes: (Summary)
So the policy in shared lpar case is to let PowerVM hypervisor know immediately that the guest cpu is idle which will allow the hypervisor to use the cycles for other tasks/lpars.

--Vaidy

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/



Re: [PATCH] cpuidle: powernv/pseries: Decrease the snooze residency

$
0
0
Vaidyanathan Srinivasan writes: (Summary) But in single threaded guest, this can force an unnecessary exit/context switch overhead.

Now that we have fixed the snooze loop to be bounded and exit predictably, KVM guest should actually use snooze state to improve latency.

I will test this scenario and enable snooze state for KVM guest. This scenario is worth experimenting and then introduce snooze loop for guest.

--Vaidy

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/


Re: [patch 10/15] sched/migration: Move calc_load_migrate() into C ...

$
0
0
Vaidyanathan Srinivasan writes: (Summary) [2016-07-12 18:33:56]:

[...]


Hi Thomas,

Yes this patch fixes the issue. I was able to recreate the problem and also verify with this patch on 4.7.0-rc7.

[...]


Tested-by: Vaidyanathan Srinivasan <svaidy@linux.vnet.ibm.com>

[...]


 if (nr_active != this_rq->calc_load_active) {
  delta = nr_active - this_rq->calc_load_active;
 }
return delta;

Does the above calculation hold good even if we send adjust=1 and bump down nr_active? Tested ok though :)

--Vaidy




Latest Images