[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20181112053147.GA78520@gmail.com>
Date: Mon, 12 Nov 2018 06:31:47 +0100
From: Ingo Molnar <mingo@...nel.org>
To: Peter Zijlstra <peterz@...radead.org>
Cc: Aubrey Li <aubrey.li@...el.com>, tglx@...utronix.de,
mingo@...hat.com, hpa@...or.com, ak@...ux.intel.com,
tim.c.chen@...ux.intel.com, arjan@...ux.intel.com,
linux-kernel@...r.kernel.org, Aubrey Li <aubrey.li@...ux.intel.com>
Subject: Re: [RFC PATCH v1 2/2] proc: add /proc/<pid>/thread_state
* Peter Zijlstra <peterz@...radead.org> wrote:
> On Thu, Nov 08, 2018 at 07:32:46AM +0100, Ingo Molnar wrote:
> >
> > * Aubrey Li <aubrey.li@...el.com> wrote:
> >
> > > Expose the per-task cpu specific thread state value, it's helpful
> > > for userland to classify and schedule the tasks by different policies
> >
> > That's pretty vague - what exactly would use this information? I'm sure
> > you have a usecase in mind - could you please describe it?
>
> Yeah, "thread_state" is a pretty terrible name for this. The use-case is
> detectoring which tasks use AVX3 such that a userspace component (think
> job scheduler) can cluster them together.
I'd prefer the kernel to do such clustering...
Thanks,
Ingo
Powered by blists - more mailing lists