On Wed, 2012-10-10 at 13:29 +0100, Mel Gorman wrote:
> Do we really switch more though?
>
> Look at the difference in interrupts vs context switch. IPIs are an interrupt
> so if TTWU_QUEUE wakes process B using an IPI, does that count as a context
> switch?
Nope. Nor would it for NO_TTWU_QUEUE. A
On Wed, 2012-10-10 at 13:29 +0100, Mel Gorman wrote:
> On Wed, Oct 03, 2012 at 03:30:01PM +0200, Mike Galbraith wrote:
> > nohz=off, pipe-test with one half pinned to CPU0, the other to CPU1.
> >
> > procs ---memory-- ---swap-- -io -system--
> > -cpu--
> > r b
On Wed, Oct 03, 2012 at 03:30:01PM +0200, Mike Galbraith wrote:
> On Wed, 2012-10-03 at 10:13 +0200, Mike Galbraith wrote:
>
> > Watching all cores instead.
> >
> > switch rate ~890KHzswitch rate ~570KHz
> > NO_TTWU_QUEUE nohz=off TTWU_QUEUE no
On Wed, Oct 03, 2012 at 11:04:16AM -0700, Rick Jones wrote:
> On 10/03/2012 02:47 AM, Mel Gorman wrote:
> >On Tue, Oct 02, 2012 at 03:48:57PM -0700, Rick Jones wrote:
> >>On 10/02/2012 01:45 AM, Mel Gorman wrote:
> >>
> >>>SIZE=64
> >>>taskset -c 0 netserver
> >>>taskset -c 1 netperf -t UDP_STREAM
On 10/03/2012 02:47 AM, Mel Gorman wrote:
On Tue, Oct 02, 2012 at 03:48:57PM -0700, Rick Jones wrote:
On 10/02/2012 01:45 AM, Mel Gorman wrote:
SIZE=64
taskset -c 0 netserver
taskset -c 1 netperf -t UDP_STREAM -i 50,6 -I 99,1 -l 20 -H 127.0.0.1 -- -P
15895 -s 32768 -S 32768 -m $SIZE -M $SIZE
On Wed, 2012-10-03 at 10:13 +0200, Mike Galbraith wrote:
> Watching all cores instead.
>
> switch rate ~890KHzswitch rate ~570KHz
> NO_TTWU_QUEUE nohz=off TTWU_QUEUE nohz=off
> 5.38% [kernel] [k] __schedule4.81% [kernel] [k
On Wed, 2012-10-03 at 10:47 +0100, Mel Gorman wrote:
> On Tue, Oct 02, 2012 at 03:48:57PM -0700, Rick Jones wrote:
> > PS - I trust it is the receive-side throughput being reported/used
> > with UDP_STREAM :)
>
> Good question. Now that I examine the scripts, it is in fact the sending
> side that
On Tue, Oct 02, 2012 at 03:48:57PM -0700, Rick Jones wrote:
> On 10/02/2012 01:45 AM, Mel Gorman wrote:
>
> >SIZE=64
> >taskset -c 0 netserver
> >taskset -c 1 netperf -t UDP_STREAM -i 50,6 -I 99,1 -l 20 -H 127.0.0.1 -- -P
> >15895 -s 32768 -S 32768 -m $SIZE -M $SIZE
>
> Just FYI, unless you are
On Wed, 2012-10-03 at 08:50 +0200, Mike Galbraith wrote:
> On Tue, 2012-10-02 at 14:14 +0100, Mel Gorman wrote:
> > On Tue, Oct 02, 2012 at 11:31:22AM +0200, Mike Galbraith wrote:
> > > On Tue, 2012-10-02 at 09:45 +0100, Mel Gorman wrote:
> > > > On Tue, Oct 02, 2012 at 09:49:36AM +0200, Mike Ga
On Tue, 2012-10-02 at 14:14 +0100, Mel Gorman wrote:
> On Tue, Oct 02, 2012 at 11:31:22AM +0200, Mike Galbraith wrote:
> > On Tue, 2012-10-02 at 09:45 +0100, Mel Gorman wrote:
> > > On Tue, Oct 02, 2012 at 09:49:36AM +0200, Mike Galbraith wrote:
> >
> > > > Hm, 518cd623 fixed up the troubles I s
On 10/02/2012 01:45 AM, Mel Gorman wrote:
SIZE=64
taskset -c 0 netserver
taskset -c 1 netperf -t UDP_STREAM -i 50,6 -I 99,1 -l 20 -H 127.0.0.1 -- -P
15895 -s 32768 -S 32768 -m $SIZE -M $SIZE
Just FYI, unless you are running a hacked version of netperf, the "50"
in "-i 50,6" will be silently
On Tue, 2012-10-02 at 14:14 +0100, Mel Gorman wrote:
> On Tue, Oct 02, 2012 at 11:31:22AM +0200, Mike Galbraith wrote:
> > On Tue, 2012-10-02 at 09:45 +0100, Mel Gorman wrote:
> > > On Tue, Oct 02, 2012 at 09:49:36AM +0200, Mike Galbraith wrote:
> >
> > > > Hm, 518cd623 fixed up the troubles I s
On Tue, Oct 02, 2012 at 11:31:22AM +0200, Mike Galbraith wrote:
> On Tue, 2012-10-02 at 09:45 +0100, Mel Gorman wrote:
> > On Tue, Oct 02, 2012 at 09:49:36AM +0200, Mike Galbraith wrote:
>
> > > Hm, 518cd623 fixed up the troubles I saw. How exactly are you running
> > > this?
> > >
> >
> > You
On Tue, 2012-10-02 at 09:45 +0100, Mel Gorman wrote:
> On Tue, Oct 02, 2012 at 09:49:36AM +0200, Mike Galbraith wrote:
> > Hm, 518cd623 fixed up the troubles I saw. How exactly are you running
> > this?
> >
>
> You saw problems with TCP_RR where as this is UDP_STREAM.
Yeah, but I wanted to st
On Tue, Oct 02, 2012 at 09:49:36AM +0200, Mike Galbraith wrote:
> On Tue, 2012-10-02 at 07:51 +0100, Mel Gorman wrote:
> > I'm going through old test results to see could I find any leftover
> > performance regressions that have not yet been fixed (most have at this
> > point
> > or at least chan
On Tue, 2012-10-02 at 07:51 +0100, Mel Gorman wrote:
> I'm going through old test results to see could I find any leftover
> performance regressions that have not yet been fixed (most have at this point
> or at least changed in such a way to make a plain revert impossible). One
> major regression
I'm going through old test results to see could I find any leftover
performance regressions that have not yet been fixed (most have at this point
or at least changed in such a way to make a plain revert impossible). One
major regression still left is with netperf UDP_STREAM regression. Bisection
po
17 matches
Mail list logo