Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Date:   Tue, 26 May 2020 22:00:15 +0200
From:   Peter Zijlstra <peterz@infradead.org>
To:     Valentin Schneider <valentin.schneider@arm.com>
Cc:     Jens Axboe <axboe@kernel.dk>, Ingo Molnar <mingo@redhat.com>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        Stefano Garzarella <sgarzare@redhat.com>
Subject: Re: [PATCH] sched/fair: don't NUMA balance for kthreads
Message-ID: <20200526200015.GG325280@hirez.programming.kicks-ass.net>
References: <865de121-8190-5d30-ece5-3b097dc74431@kernel.dk>
 <jhjpnaqtztl.mognet@arm.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <jhjpnaqtztl.mognet@arm.com>
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Tue, May 26, 2020 at 05:40:06PM +0100, Valentin Schneider wrote:

> > Change the task_tick_numa() check to exclude kernel threads in general,
> > as it doesn't make sense to attempt ot balance for kthreads anyway.
> >
> 
> Does it? (this isn't a rethorical question)
> 
> Suppose a given kthread ends up doing more accesses to some pages
> (via use_mm()) than the other threads that access them, wouldn't it make
> sense to take that into account when it comes to NUMA balancing?

Well, task_tick_numa() tries and farm off a bunch of actual work to
task_work_add(), and there's so very little userspace for a kernel
thread to return to... :-)