On Mon, Apr 14, 2014 at 09:34:19AM -0400, Steven Rostedt wrote:
> On Mon, 14 Apr 2014 11:55:54 +0200
> Ingo Molnar wrote:
>
> > > Index: linux-rt.git/kernel/rtmutex.c
> >
> > Side note: could you please in general include diffstats with such
> > patches, especially since you seem to be export
On Mon, 14 Apr 2014 11:55:54 +0200
Ingo Molnar wrote:
> > Index: linux-rt.git/kernel/rtmutex.c
>
> Side note: could you please in general include diffstats with such
> patches, especially since you seem to be exporting it from a Git repo?
Sure, I'll try to remember to add them. I do my work
* Steven Rostedt wrote:
> A while back ago I wrote a patch that would allow for reader/writer
> locks like rwlock and rwsems to have multiple readers in PREEMPT_RT. It
> was slick and fast but unfortunately it was way too complex and ridden
> with nasty little critters which earned me my large c
On 04/10/2014 11:44 AM, Clark Williams wrote:
On Wed, 9 Apr 2014 15:19:22 -0400
Steven Rostedt wrote:
This patch is built on top of the two other patches that I posted
earlier, which should not be as controversial.
If you have any benchmark on large machines I would be very happy if
you co
On Fri, 2014-04-11 at 05:52 +0200, Mike Galbraith wrote:
> On Thu, 2014-04-10 at 23:25 -0400, Steven Rostedt wrote:
> > On Fri, 11 Apr 2014 04:50:26 +0200
> > Mike Galbraith wrote:
> >
> > > Oh, there was another useful bit.
> > >
> > > 3.12.17-rt25 403991 384216 377786
> > >
On Thu, 2014-04-10 at 23:25 -0400, Steven Rostedt wrote:
> On Fri, 11 Apr 2014 04:50:26 +0200
> Mike Galbraith wrote:
>
> > Oh, there was another useful bit.
> >
> > 3.12.17-rt25 403991 384216 377786
> >405466 394011 392850
> >
> > 3.12.17-nopreempt
On Fri, 11 Apr 2014 04:50:26 +0200
Mike Galbraith wrote:
> Oh, there was another useful bit.
>
> 3.12.17-rt25 403991 384216 377786
>405466 394011 392850
>
> 3.12.17-nopreempt 109049 186133 118766 !?!.. ew, TTWU_QUEUE
>3503
Oh, there was another useful bit.
3.12.17-rt25 403991 384216 377786
405466 394011 392850
3.12.17-nopreempt 109049 186133 118766 !?!.. ew, TTWU_QUEUE
350385 318786 367336 !TTWU_QUEUE
326009 35693
On Thu, 10 Apr 2014 14:30:03 -0700
"Paul E. McKenney" wrote:
> On Thu, Apr 10, 2014 at 03:17:41PM -0400, Steven Rostedt wrote:
> > On Thu, 10 Apr 2014 17:36:17 +0200
> > Peter Zijlstra wrote:
> >
> >
> > > It defaults to the total number of CPUs in the system, given the default
> > > setup (al
On Thu, Apr 10, 2014 at 03:17:41PM -0400, Steven Rostedt wrote:
> On Thu, 10 Apr 2014 17:36:17 +0200
> Peter Zijlstra wrote:
>
>
> > It defaults to the total number of CPUs in the system, given the default
> > setup (all CPUs in a single balance domain), this should result in all
> > CPUs workin
On Thu, Apr 10, 2014 at 03:17:41PM -0400, Steven Rostedt wrote:
> On Thu, 10 Apr 2014 17:36:17 +0200
> Peter Zijlstra wrote:
>
>
> > It defaults to the total number of CPUs in the system, given the default
> > setup (all CPUs in a single balance domain), this should result in all
> > CPUs workin
On Thu, 10 Apr 2014 17:36:17 +0200
Peter Zijlstra wrote:
> It defaults to the total number of CPUs in the system, given the default
> setup (all CPUs in a single balance domain), this should result in all
> CPUs working concurrently on the boosted read sides.
Unfortunately, it currently default
On Thu, Apr 10, 2014 at 05:03:36PM +0200, Sebastian Andrzej Siewior wrote:
> On 04/10/2014 04:44 PM, Clark Williams wrote:
> > The means of each group of five test runs are:
> >
> > vanilla.log: 1210117 rt.log: 17210953 (14.2 x slower than
> > vanilla) rt-fixes.log: 10062027 (8.3 x slower than
On Thu, 10 Apr 2014 17:03:36 +0200
Sebastian Andrzej Siewior wrote:
> On 04/10/2014 04:44 PM, Clark Williams wrote:
> > The means of each group of five test runs are:
> >
> > vanilla.log: 1210117 rt.log: 17210953 (14.2 x slower than
> > vanilla) rt-fixes.log: 10062027 (8.3 x slower than vanil
On 04/10/2014 04:44 PM, Clark Williams wrote:
> The means of each group of five test runs are:
>
> vanilla.log: 1210117 rt.log: 17210953 (14.2 x slower than
> vanilla) rt-fixes.log: 10062027 (8.3 x slower than vanilla)
> rt-multi.log: 3179582 (2.x x slower than vanilla)
>
>
> As expected,
On Thu, 10 Apr 2014 09:44:30 -0500
Clark Williams wrote:
> I wrote a program named whack_mmap_sem which creates a large (4GB)
> buffer, then creates 2 x ncpus threads that are affined across all the
> available cpus. These threads then randomly write into the buffer,
> which should cause page fau
On Wed, 9 Apr 2014 15:19:22 -0400
Steven Rostedt wrote:
> This patch is built on top of the two other patches that I posted
> earlier, which should not be as controversial.
>
> If you have any benchmark on large machines I would be very happy if
> you could test this patch against the unpatche
On Thu, 10 Apr 2014 16:28:43 +0200
Mike Galbraith wrote:
> On Thu, 2014-04-10 at 16:18 +0200, Mike Galbraith wrote:
> > On Wed, 2014-04-09 at 15:19 -0400, Steven Rostedt wrote:
> >
> > > If you have any benchmark on large machines I would be very happy if
> > > you could test this patch against
On Thu, 2014-04-10 at 16:18 +0200, Mike Galbraith wrote:
> On Wed, 2014-04-09 at 15:19 -0400, Steven Rostedt wrote:
>
> > If you have any benchmark on large machines I would be very happy if
> > you could test this patch against the unpatched version of -rt.
>
> Too bad I don't have (and know ho
On Wed, 2014-04-09 at 15:19 -0400, Steven Rostedt wrote:
> If you have any benchmark on large machines I would be very happy if
> you could test this patch against the unpatched version of -rt.
Too bad I don't have (and know how to use) specjbb.
I dug up old vmark, thinking I'd be able to get so
A while back ago I wrote a patch that would allow for reader/writer
locks like rwlock and rwsems to have multiple readers in PREEMPT_RT. It
was slick and fast but unfortunately it was way too complex and ridden
with nasty little critters which earned me my large collection of
frozen sharks in the f
21 matches
Mail list logo