From: Alan Cox <alan@lxorguk.ukuu.org.uk>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Ingo Molnar <mingo@elte.hu>, Stijn Devriendt <highguy@gmail.com>,
Mike Galbraith <efault@gmx.de>,
Peter Zijlstra <a.p.zijlstra@chello.nl>,
Andrea Arcangeli <andrea@suse.de>,
Thomas Gleixner <tglx@linutronix.de>,
Andrew Morton <akpm@linux-foundation.org>,
peterz@infradead.org, linux-kernel@vger.kernel.org
Subject: Re: [RFC] observe and act upon workload parallelism: PERF_TYPE_PARALLELISM (Was: [RFC][PATCH] sched_wait_block: wait for blocked threads)
Date: Mon, 16 Nov 2009 18:31:17 +0000 [thread overview]
Message-ID: <20091116183117.48a02426@lxorguk.ukuu.org.uk> (raw)
In-Reply-To: <alpine.LFD.2.01.0911160945470.9384@localhost.localdomain>
On Mon, 16 Nov 2009 10:02:50 -0800 (PST)
Linus Torvalds <torvalds@linux-foundation.org> wrote:
>
>
> On Mon, 16 Nov 2009, Ingo Molnar wrote:
> >
> > Regarding the API and your patch, i think we can and should do something
> > different and more capable - while still keeping your basic idea:
>
> Actually, I'd suggest exactly the reverse.
>
> Yes, do something different, but _less_ capable, and much simpler:
> introduce the notion of "grouped thread scheduling", where a _group_ of
> threads gets scheduled as one thread.
And preferably expose it so it can be used by groups of processes as well
as just "threads" in the userspace shared pid etc sense. There are quite
a few applications where both "only run one of us" and "don't pre-empt
within the group" are a useful semantic (you often don't want the
pre-empting within the group of threads because it messes up all the
improved locking opportunities). In particular the usual buzz locks don't
mix well with "only run one of us".
Alan
next prev parent reply other threads:[~2009-11-16 18:30 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-11-15 19:04 [RFC][PATCH] sched_wait_block: wait for blocked threads Stijn Devriendt
2009-11-15 19:04 ` [PATCH] Initial prototype version of sched_wait_block Stijn Devriendt
2009-11-16 8:35 ` [RFC] observe and act upon workload parallelism: PERF_TYPE_PARALLELISM (Was: [RFC][PATCH] sched_wait_block: wait for blocked threads) Ingo Molnar
2009-11-16 18:02 ` Linus Torvalds
2009-11-16 18:18 ` Linus Torvalds
2009-11-16 18:31 ` Alan Cox [this message]
2009-11-16 19:49 ` Stijn Devriendt
2009-11-16 20:13 ` Ingo Molnar
2009-11-21 11:26 ` Stijn Devriendt
2009-11-16 19:13 ` Stijn Devriendt
2009-11-16 20:22 ` Ingo Molnar
2009-11-18 9:30 ` Stijn Devriendt
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=20091116183117.48a02426@lxorguk.ukuu.org.uk \
--to=alan@lxorguk.ukuu.org.uk \
--cc=a.p.zijlstra@chello.nl \
--cc=akpm@linux-foundation.org \
--cc=andrea@suse.de \
--cc=efault@gmx.de \
--cc=highguy@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=peterz@infradead.org \
--cc=tglx@linutronix.de \
--cc=torvalds@linux-foundation.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®