On Tue, May 12, 2015 at 7:04 PM, Vladimir Davydov
wrote:
> Hi,
>
> This patch set introduces a new user API for tracking user memory pages
> that have not been used for a given period of time. The purpose of this
> is to provide the userspace with the means of tracking a workload's
> working set,
On Tue, May 12, 2015 at 7:04 PM, Vladimir Davydov
vdavy...@parallels.com wrote:
Hi,
This patch set introduces a new user API for tracking user memory pages
that have not been used for a given period of time. The purpose of this
is to provide the userspace with the means of tracking a
On Wed, Oct 8, 2014 at 12:37 PM, Preeti U Murthy
wrote:
> There are two masks associated with cpusets. The cpus/mems_allowed
> and effective_cpus/mems. On the legacy hierarchy both these masks
> are consistent with each other. This is the intersection of their
> value and the currently active
On Wed, Oct 8, 2014 at 12:37 PM, Preeti U Murthy
pre...@linux.vnet.ibm.com wrote:
There are two masks associated with cpusets. The cpus/mems_allowed
and effective_cpus/mems. On the legacy hierarchy both these masks
are consistent with each other. This is the intersection of their
value and the
On Fri, May 23, 2014 at 3:50 PM, Dan Carpenter wrote:
> yield_to() is supposed to return -ESRCH if there is no task to
> yield to, but because the type is bool that is the same as returning
> true.
>
> The only place I see which cares is kvm_vcpu_on_spin().
>
> Signed-off-by: Dan Carpenter
On Fri, May 23, 2014 at 3:50 PM, Dan Carpenter dan.carpen...@oracle.com wrote:
yield_to() is supposed to return -ESRCH if there is no task to
yield to, but because the type is bool that is the same as returning
true.
The only place I see which cares is kvm_vcpu_on_spin().
Signed-off-by: Dan
On 5/2/14, Tejun Heo wrote:
> Hello,
>
> On Wed, Apr 30, 2014 at 04:27:51PM +0530, Raghavendra KT wrote:
[...]
>> Because all the way along, though we have freedom to make the cpusets
>> exclusive and move tasks (say VMs) into them,
>> making sure they do not interf
On 5/2/14, Tejun Heo t...@kernel.org wrote:
Hello,
On Wed, Apr 30, 2014 at 04:27:51PM +0530, Raghavendra KT wrote:
[...]
Because all the way along, though we have freedom to make the cpusets
exclusive and move tasks (say VMs) into them,
making sure they do not interfere with each other, we
On Mon, Apr 14, 2014 at 11:22 PM, Tejun Heo wrote:
>> How does this work for root's tasks now? Given that task can only be
>> in leaf cgroups, that means tasks can't be in / cgroup (If one wants
>> to create some cgroups). Does that mean / will be empty and init system
>> need to setup things
On Tue, Apr 15, 2014 at 3:06 AM, Tejun Heo wrote:
> Hello,
>
> This is v2 of the unified hierarchy patchset. Changes from v1[1] are,
>
> * Rebased on top of v3.15-rc1
>
> * Interface file "cgroup.controllers" which was only available in the
> root is now available in all cgroups. This allows,
On Tue, Apr 15, 2014 at 3:06 AM, Tejun Heo t...@kernel.org wrote:
Hello,
This is v2 of the unified hierarchy patchset. Changes from v1[1] are,
* Rebased on top of v3.15-rc1
* Interface file cgroup.controllers which was only available in the
root is now available in all cgroups. This
On Mon, Apr 14, 2014 at 11:22 PM, Tejun Heo t...@kernel.org wrote:
How does this work for root's tasks now? Given that task can only be
in leaf cgroups, that means tasks can't be in / cgroup (If one wants
to create some cgroups). Does that mean / will be empty and init system
need to setup
On Tue, Apr 15, 2014 at 3:07 AM, Tejun Heo wrote:
[...]
> * White-space separated list of controller names prefixed with either
> '+' or '-' can be written to "cgroup.subtree_control". The ones
> prefixed with '+' are enabled on the controller and '-' disabled.
>
[...]
> +
> +/* change the
On Tue, Apr 15, 2014 at 3:07 AM, Tejun Heo t...@kernel.org wrote:
[...]
* White-space separated list of controller names prefixed with either
'+' or '-' can be written to cgroup.subtree_control. The ones
prefixed with '+' are enabled on the controller and '-' disabled.
[...]
+
+/*
On Mon, Mar 3, 2014 at 11:54 PM, Li, Bin (Bin)
wrote:
> Hello, all.
>
> The PLE handler attempts to determine an alternate vCPU to schedule. In
> some cases the wrong vCPU is scheduled and performance suffers.
>
> This patch allows for the guest OS to signal, using a hypercall, that it's
>
On Mon, Mar 3, 2014 at 11:54 PM, Li, Bin (Bin)
bin.bl...@alcatel-lucent.com wrote:
Hello, all.
The PLE handler attempts to determine an alternate vCPU to schedule. In
some cases the wrong vCPU is scheduled and performance suffers.
This patch allows for the guest OS to signal, using a
On Mon, Feb 10, 2014 at 8:40 AM, Benjamin Herrenschmidt
wrote:
> On Fri, 2014-02-07 at 17:58 +0100, Torsten Duwe wrote:
>> typedef struct {
>> - volatile unsigned int slock;
>> -} arch_spinlock_t;
>> + union {
>> + __ticketpair_t head_tail;
>> + struct
On Fri, Feb 7, 2014 at 10:28 PM, Torsten Duwe wrote:
> Ticket locks for ppc, version 2. Changes since v1:
> * The atomically exchanged entity is always 32 bits.
> * asm inline string variations thus removed.
> * Carry the additional holder hint only #if defined(CONFIG_PPC_SPLPAR)
>
>
On Fri, Feb 7, 2014 at 10:28 PM, Torsten Duwe d...@lst.de wrote:
Ticket locks for ppc, version 2. Changes since v1:
* The atomically exchanged entity is always 32 bits.
* asm inline string variations thus removed.
* Carry the additional holder hint only #if defined(CONFIG_PPC_SPLPAR)
On Mon, Feb 10, 2014 at 8:40 AM, Benjamin Herrenschmidt
b...@kernel.crashing.org wrote:
On Fri, 2014-02-07 at 17:58 +0100, Torsten Duwe wrote:
typedef struct {
- volatile unsigned int slock;
-} arch_spinlock_t;
+ union {
+ __ticketpair_t head_tail;
+
On Fri, Oct 4, 2013 at 8:33 PM, Steven Rostedt wrote:
CCing my IBM id
> >
> > Bisection identified this as the problem commit.
> >
> > 9c85f3bdf400665eecf62658a9106501f6a77a13 is the first bad commit
> > commit 9c85f3bdf400665eecf62658a9106501f6a77a13
> > Author: Steven Rostedt
> > Date: Thu
On Fri, Oct 4, 2013 at 8:33 PM, Steven Rostedt rost...@goodmis.org wrote:
CCing my IBM id
Bisection identified this as the problem commit.
9c85f3bdf400665eecf62658a9106501f6a77a13 is the first bad commit
commit 9c85f3bdf400665eecf62658a9106501f6a77a13
Author: Steven Rostedt
On Wed, Jul 17, 2013 at 5:14 AM, Dave Hansen wrote:
>
> I was investigating some TLB flush scaling issues and realized
> that we do not have any good methods for figuring out how many
> TLB flushes we are doing.
>
> It would be nice to be able to do these in generic code, but the
>
On Wed, Jul 17, 2013 at 5:14 AM, Dave Hansen d...@sr71.net wrote:
I was investigating some TLB flush scaling issues and realized
that we do not have any good methods for figuring out how many
TLB flushes we are doing.
It would be nice to be able to do these in generic code, but the
On Sun, Jun 23, 2013 at 11:23 PM, Raghavendra KT
wrote:
>
>
> On Wed, Jun 12, 2013 at 9:10 PM, Paul E. McKenney
> wrote:
>>
>> Breaking up locks is better than implementing high-contention locks, but
>> if we must have high-contention locks, why not make them a
On Sun, Jun 23, 2013 at 11:23 PM, Raghavendra KT
raghavendra.kt.li...@gmail.com wrote:
On Wed, Jun 12, 2013 at 9:10 PM, Paul E. McKenney
paul...@linux.vnet.ibm.com wrote:
Breaking up locks is better than implementing high-contention locks, but
if we must have high-contention locks, why
On Fri, Feb 22, 2013 at 4:56 AM, Marcelo Tosatti wrote:
> On Thu, Feb 21, 2013 at 09:56:54AM +0100, Ingo Molnar wrote:
>>
>> * Shuah Khan wrote:
>>
>> > On Tue, Feb 19, 2013 at 7:27 PM, Linux Kernel Mailing List
>> > wrote:
>> > > Gitweb:
>> > >
On Thu, Feb 21, 2013 at 2:26 PM, Ingo Molnar wrote:
>
> * Shuah Khan wrote:
>
>> On Tue, Feb 19, 2013 at 7:27 PM, Linux Kernel Mailing List
>> wrote:
>> > Gitweb:
>> > http://git.kernel.org/linus/;a=commit;h=c3c186403c6abd32e719f005f0af950155a9e54d
>> > Commit:
On Thu, Feb 21, 2013 at 2:26 PM, Ingo Molnar mi...@kernel.org wrote:
* Shuah Khan shuahk...@gmail.com wrote:
On Tue, Feb 19, 2013 at 7:27 PM, Linux Kernel Mailing List
linux-kernel@vger.kernel.org wrote:
Gitweb:
On Fri, Feb 22, 2013 at 4:56 AM, Marcelo Tosatti mtosa...@redhat.com wrote:
On Thu, Feb 21, 2013 at 09:56:54AM +0100, Ingo Molnar wrote:
* Shuah Khan shuahk...@gmail.com wrote:
On Tue, Feb 19, 2013 at 7:27 PM, Linux Kernel Mailing List
linux-kernel@vger.kernel.org wrote:
Gitweb:
[Ccing IBM id]
On Thu, Jan 3, 2013 at 10:52 AM, Rik van Riel wrote:
> Simple fixed value proportional backoff for ticket spinlocks.
> By pounding on the cacheline with the spin lock less often,
> bus traffic is reduced. In cases of a data structure with
> embedded spinlock, the lock holder has a
[CCing my ibm id]
On Thu, Jan 3, 2013 at 10:45 AM, Rik van Riel wrote:
> Many spinlocks are embedded in data structures; having many CPUs
> pounce on the cache line the lock is in will slow down the lock
> holder, and can cause system performance to fall off a cliff.
>
> The paper "Non-scalable
[CCing my ibm id]
On Thu, Jan 3, 2013 at 10:45 AM, Rik van Riel r...@redhat.com wrote:
Many spinlocks are embedded in data structures; having many CPUs
pounce on the cache line the lock is in will slow down the lock
holder, and can cause system performance to fall off a cliff.
The paper
[Ccing IBM id]
On Thu, Jan 3, 2013 at 10:52 AM, Rik van Riel r...@redhat.com wrote:
Simple fixed value proportional backoff for ticket spinlocks.
By pounding on the cacheline with the spin lock less often,
bus traffic is reduced. In cases of a data structure with
embedded spinlock, the lock
34 matches
Mail list logo
