From: Ingo Molnar <mingo@elte.hu>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Max Krasnyansky <maxk@qualcomm.com>,
Andrew Morton <akpm@linux-foundation.org>,
LKML <linux-kernel@vger.kernel.org>
Subject: Re: [git pull] CPU isolation extensions
Date: Thu, 7 Feb 2008 20:51:30 +0100 [thread overview]
Message-ID: <20080207195130.GA27482@elte.hu> (raw)
In-Reply-To: <alpine.LFD.1.00.0802070903190.2883@woody.linux-foundation.org>
* Linus Torvalds <torvalds@linux-foundation.org> wrote:
> On Wed, 6 Feb 2008, Max Krasnyansky wrote:
> >
> > Linus, please pull CPU isolation extensions from
> >
> > git://git.kernel.org/pub/scm/linux/kernel/git/maxk/cpuisol-2.6.git
> > for-linus
>
> Have these been in -mm and widely discussed etc? I'd like to start
> more carefully, and (a) have that controversial last patch not merged
> initially and (b) make sure everybody is on the same page wrt this
> all..
no, they have not been under nearly enough testing and review - these
patches surfaced on lkml for the first time one week ago (!). I find the
pull request totally premature, this stuff has not been discussed and
agreed on _at all_. None of the people who maintain and have interest in
this code and participated in the (short) one-week discussion were
Cc:-ed to the pull request.
I think these patches also need a buy-in from Peter Zijlstra and Paul
Jackson (or really good reasoning while any objections from them should
be overriden) - all of whom deal with the code affected by these changes
on a daily basis and have an interest in CPU isolation features.
Generally i think that cpusets is actually the feature and API that
should be used (and extended) for CPU isolation - and we already
extended it recently in the direction of CPU isolation. Most enterprise
distros have cpusets enabled so it's in use. Also, cpusets has the
appeal of being commonly used in the "big honking boxes" arena, so
reusing the same concept for RT and virtualization stuff would be the
natural approach. It already ties in to the scheduler domains code
dynamically and is flexible and scalable. I resisted ad-hoc CPU
isolation patches in -rt for that reason. Also, i'd not mind some
test-coverage in sched.git as well.
Ingo
next prev parent reply other threads:[~2008-02-07 19:52 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-02-07 5:32 [git pull] CPU isolation extensions Max Krasnyansky
2008-02-07 5:58 ` Andrew Morton
2008-02-07 7:59 ` Paul Jackson
2008-02-07 8:12 ` Andrew Morton
2008-02-07 18:14 ` Max Krasnyansky
2008-02-07 18:02 ` Max Krasnyansky
2008-02-07 18:10 ` Paul Jackson
2008-02-07 18:22 ` Max Krasnyansky
2008-02-07 17:22 ` Max Krasnyansky
2008-02-07 19:26 ` Andrew Morton
2008-02-07 17:06 ` Linus Torvalds
2008-02-07 17:36 ` Max Krasnyansky
2008-02-07 19:51 ` Ingo Molnar [this message]
2008-02-08 0:38 ` Max Krasnyansky
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=20080207195130.GA27482@elte.hu \
--to=mingo@elte.hu \
--cc=akpm@linux-foundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=maxk@qualcomm.com \
--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