Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
MIME-Version: 1.0
References: <20191115234005.GO4614@dread.disaster.area> <20191118092121.GV4131@hirez.programming.kicks-ass.net>
 <20191118204054.GV4614@dread.disaster.area> <20191120191636.GI4097@hirez.programming.kicks-ass.net>
 <20191120220313.GC18056@pauld.bos.csb> <20191121132937.GW4114@hirez.programming.kicks-ass.net>
 <20191209165122.GA27229@linux.vnet.ibm.com> <20191209231743.GA19256@dread.disaster.area>
 <20191210054330.GF27253@linux.vnet.ibm.com> <CAKfTPtCBxV+az30n8E9fRv_HweN_QPJn_ni961OsKp5xUWUD2A@mail.gmail.com>
 <20191210101116.GA9139@linux.vnet.ibm.com>
In-Reply-To: <20191210101116.GA9139@linux.vnet.ibm.com>
From:   Vincent Guittot <vincent.guittot@linaro.org>
Date:   Tue, 10 Dec 2019 12:02:09 +0100
Message-ID: <CAKfTPtD1by06eQ=vJhh9SvfegRanSSwQrKPageLGo0OODu9bjg@mail.gmail.com>
Subject: Re: [PATCH v2] sched/core: Preempt current task in favour of bound kthread
To:     Srikar Dronamraju <srikar@linux.vnet.ibm.com>
Cc:     Dave Chinner <david@fromorbit.com>,
        Peter Zijlstra <peterz@infradead.org>,
        Phil Auld <pauld@redhat.com>, Ming Lei <ming.lei@redhat.com>,
        linux-block <linux-block@vger.kernel.org>,
        linux-fs <linux-fsdevel@vger.kernel.org>,
        linux-xfs <linux-xfs@vger.kernel.org>,
        linux-kernel <linux-kernel@vger.kernel.org>,
        Jeff Moyer <jmoyer@redhat.com>,
        Dave Chinner <dchinner@redhat.com>,
        Eric Sandeen <sandeen@redhat.com>,
        Christoph Hellwig <hch@lst.de>, Jens Axboe <axboe@kernel.dk>,
        Ingo Molnar <mingo@redhat.com>, Tejun Heo <tj@kernel.org>
Content-Type: text/plain; charset="UTF-8"
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Tue, 10 Dec 2019 at 11:11, Srikar Dronamraju
<srikar@linux.vnet.ibm.com> wrote:
>
> * Vincent Guittot <vincent.guittot@linaro.org> [2019-12-10 10:43:46]:
>
> > On Tue, 10 Dec 2019 at 06:43, Srikar Dronamraju
> > <srikar@linux.vnet.ibm.com> wrote:
> > >
> > > This is more prone to happen if the current running task is CPU
> > > intensive and the sched_wake_up_granularity is set to larger value.
> > > When the sched_wake_up_granularity was relatively small, it was observed
> > > that the bound thread would complete before the load balancer would have
> > > chosen to move the cache hot task to a different CPU.
> > >
> > > To deal with this situation, the current running task would yield to a
> > > per CPU bound kthread, provided kthread is not CPU intensive.
> > >
> > > /pboffline/hwcct_prg_old/lib/fsperf -t overwrite --noclean -f 5g -b 4k /pboffline
> > >
> > > (With sched_wake_up_granularity set to 15ms)
> >
> > So you increase sched_wake_up_granularity to a high level to ensure
> > that current is no preempted by waking thread but then you add a way
> > to finally preempt it which is somewhat weird IMO
> >
>
> Yes, setting to a smaller value will help mitigate/solve the problem.
> There may be folks out who have traditionally set a high wake_up_granularity
> (and have seen better performance with it), who may miss out that when using
> blk-mq, such settings will cause more harm. And they may continue to see
> some performance regressions when they move to a lower wake_up_granularity.
>
> > Have you tried to increase the priority of workqueue thread  (decrease
> > nice priority) ? This is the right way to reduce the impact of the
> > sched_wake_up_granularity on the wakeup of your specific kthread.
> > Because what you want at the end is keeping a low wakeup granularity
> > for these io workqueues
> >
>
> Yes, people can tune the priority of workqueue threads and infact it may be
> easier to set wake_up_granularity to a lower value. However the point is how
> do we make everyone aware that they are running into a performance issue
> with a higher wakeup_granularity?

I did the test on my local setup to change the nice priority of io
workqueue and the active migrations are removed even with high
wakeup_granularity because IO workqueue can still preempt normal task
but let other workqueue behave normally.

>
> --
> Thanks and Regards
> Srikar Dronamraju
>