* Mike Galbraith wrote:
> On Thu, 2013-01-10 at 10:31 -0500, Rik van Riel wrote:
> > On 01/10/2013 10:19 AM, Mike Galbraith wrote:
> > > On Tue, 2013-01-08 at 17:26 -0500, Rik van Riel wrote:
> > >
> > >> Please let me know if you manage to break this code in any way,
> > >> so I can fix it...
On 01/12/2013 01:41 AM, Rik van Riel wrote:
On 01/10/2013 12:36 PM, Raghavendra K T wrote:
* Rafael Aquini [2013-01-10 00:27:23]:
On Wed, Jan 09, 2013 at 06:20:35PM +0530, Raghavendra K T wrote:
I ran kernbench on 32 core (mx3850) machine with 3.8-rc2 base.
x base_3.8rc2
+ rik_backoff
N
On 01/10/2013 12:36 PM, Raghavendra K T wrote:
* Rafael Aquini [2013-01-10 00:27:23]:
On Wed, Jan 09, 2013 at 06:20:35PM +0530, Raghavendra K T wrote:
I ran kernbench on 32 core (mx3850) machine with 3.8-rc2 base.
x base_3.8rc2
+ rik_backoff
N Min MaxMedian
On 1/8/2013 2:26 PM, Rik van Riel wrote:
<...>
Performance is within the margin of error of v2, so the graph
has not been update.
Please let me know if you manage to break this code in any way,
so I can fix it...
Attached below is some preliminary data with one of the AIM7 micro-benchmark
wor
On Thu, 2013-01-10 at 10:31 -0500, Rik van Riel wrote:
> On 01/10/2013 10:19 AM, Mike Galbraith wrote:
> > On Tue, 2013-01-08 at 17:26 -0500, Rik van Riel wrote:
> >
> >> Please let me know if you manage to break this code in any way,
> >> so I can fix it...
> >
> > I didn't break it, but did let
* Rafael Aquini [2013-01-10 00:27:23]:
> On Wed, Jan 09, 2013 at 06:20:35PM +0530, Raghavendra K T wrote:
> > I ran kernbench on 32 core (mx3850) machine with 3.8-rc2 base.
> > x base_3.8rc2
> > + rik_backoff
> > N Min MaxMedian AvgStddev
> > x
On 01/10/2013 10:19 AM, Mike Galbraith wrote:
On Tue, 2013-01-08 at 17:26 -0500, Rik van Riel wrote:
Please let me know if you manage to break this code in any way,
so I can fix it...
I didn't break it, but did let it play with rq->lock contention. Using
cyclictest -Smp99 -i 100 -d 0, with 3
On Tue, 2013-01-08 at 17:26 -0500, Rik van Riel wrote:
> Please let me know if you manage to break this code in any way,
> so I can fix it...
I didn't break it, but did let it play with rq->lock contention. Using
cyclictest -Smp99 -i 100 -d 0, with 3 rt tasks for pull_rt_task() to
pull around ap
On Wed, Jan 09, 2013 at 06:20:35PM +0530, Raghavendra K T wrote:
> I ran kernbench on 32 core (mx3850) machine with 3.8-rc2 base.
> x base_3.8rc2
> + rik_backoff
> N Min MaxMedian AvgStddev
> x 8 222.977231.16 227.735 227
On 01/09/2013 03:56 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 locks are dangerous" is a good refere
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 locks are dangerous" is a good reference:
http://pdos.csail.mit.edu/papers
[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 lo
On Wed, Jan 2, 2013 at 9:15 PM, Rik van Riel wrote:
> The v2 series integrates several ideas from Michel Lespinasse
> and Eric Dumazet, which should result in better throughput and
> nicer behaviour in situations with contention on multiple locks.
>
> Please let me know if you manage to break this
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 locks are dangerous" is a good reference:
http://pdos.csail.mit.edu/papers
14 matches
Mail list logo
