All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Li, Aubrey" <aubrey.li@linux.intel.com>
To: Ingo Molnar <mingo@kernel.org>, Peter Zijlstra <peterz@infradead.org>
Cc: Aubrey Li <aubrey.li@intel.com>,
	tglx@linutronix.de, mingo@redhat.com, hpa@zytor.com,
	ak@linux.intel.com, tim.c.chen@linux.intel.com,
	arjan@linux.intel.com, linux-kernel@vger.kernel.org
Subject: Re: [RFC PATCH v1 2/2] proc: add /proc/<pid>/thread_state
Date: Mon, 12 Nov 2018 15:53:28 +0800	[thread overview]
Message-ID: <a9da1af4-a71a-1188-9806-f3832359d07f@linux.intel.com> (raw)
In-Reply-To: <20181112053147.GA78520@gmail.com>

On 2018/11/12 13:31, Ingo Molnar wrote:
> 
> * Peter Zijlstra <peterz@infradead.org> wrote:
> 
>> On Thu, Nov 08, 2018 at 07:32:46AM +0100, Ingo Molnar wrote:
>>>
>>> * Aubrey Li <aubrey.li@intel.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...
> 
Some userland application projects like Kubernetes request an interface of 
such information, we could do the clustering either in the kernel or from
userland, does it make sense we expose the information via the proposed 
interface first?

Thanks,
-Aubrey

  reply	other threads:[~2018-11-12  7:53 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-11-06 18:23 [RFC PATCH v1 1/2] x86/fpu: detect AVX task Aubrey Li
2018-11-06 18:23 ` [RFC PATCH v1 2/2] proc: add /proc/<pid>/thread_state Aubrey Li
2018-11-08  6:32   ` Ingo Molnar
2018-11-08 10:17     ` Peter Zijlstra
2018-11-08 14:03       ` Li, Aubrey
2018-11-12  5:31       ` Ingo Molnar
2018-11-12  7:53         ` Li, Aubrey [this message]
2018-11-12  8:56         ` Peter Zijlstra
2018-11-12 14:21           ` Arjan van de Ven
2018-11-07 17:41 ` [RFC PATCH v1 1/2] x86/fpu: detect AVX task Tim Chen
2018-11-08  0:31   ` Li, Aubrey

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=a9da1af4-a71a-1188-9806-f3832359d07f@linux.intel.com \
    --to=aubrey.li@linux.intel.com \
    --cc=ak@linux.intel.com \
    --cc=arjan@linux.intel.com \
    --cc=aubrey.li@intel.com \
    --cc=hpa@zytor.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@kernel.org \
    --cc=mingo@redhat.com \
    --cc=peterz@infradead.org \
    --cc=tglx@linutronix.de \
    --cc=tim.c.chen@linux.intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.