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;
Date:   Tue, 10 Dec 2019 15:41:16 +0530
From:   Srikar Dronamraju <srikar@linux.vnet.ibm.com>
To:     Vincent Guittot <vincent.guittot@linaro.org>
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>
Subject: Re: [PATCH v2] sched/core: Preempt current task in favour of bound
 kthread
Reply-To: Srikar Dronamraju <srikar@linux.vnet.ibm.com>
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>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
In-Reply-To: <CAKfTPtCBxV+az30n8E9fRv_HweN_QPJn_ni961OsKp5xUWUD2A@mail.gmail.com>
User-Agent: Mutt/1.10.1 (2018-07-13)
Message-Id: <20191210101116.GA9139@linux.vnet.ibm.com>
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

* 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?

-- 
Thanks and Regards
Srikar Dronamraju