LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Max Krasnyansky <maxk@qualcomm.com>
To: Paul Jackson <pj@sgi.com>
Cc: torvalds@linux-foundation.org, akpm@linux-foundation.org,
	linux-kernel@vger.kernel.org, mingo@elte.hu,
	a.p.zijlstra@chello.nl, gregkh@suse.de, rusty@rustcorp.com.au
Subject: Re: [git pull] CPU isolation extensions (updated)
Date: Sat, 09 Feb 2008 19:59:52 -0800	[thread overview]
Message-ID: <47AE76B8.6060304@qualcomm.com> (raw)
In-Reply-To: <20080209212156.ecc72fee.pj@sgi.com>

Paul Jackson wrote:
> Max wrote:
>> Linus, please pull CPU isolation extensions from
> 
> Did I miss something in this discussion?  I thought
> Ingo was quite clear, and Linus pretty clear too,
> that this patch should bake in *-mm or some such
> place for a bit first.
> 

Andrew said:
> The feature as a whole seems useful, and I don't actually oppose the merge
> based on what I see here.  As long as you're really sure that cpusets are
> inappropriate (and bear in mind that Paul has a track record of being wrong
> on this :)).  But I see a few glitches ....

As far as I can understand Andrew is ok with the merge. And I addressed all 
his comments.

Linus said:
> 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..

As far as I can understand Linus _asked_ whether it was in -mm or not and whether
everybody's on the same page. He did not say "this must be in -mm first".
I explained that it has not been in -mm, and who it was discussed with, and did a 
bunch more testing/investigation on the controversial patch and explained why I think 
it's not that controversial any more.

Ingo said a few different things (a bit too large to quote). 
- That it was not discussed. I explained that it was in fact discussed and provided
a bunch of pointers to the mail threads.
- That he thinks that cpuset is the way to do it. Again I explained why it's not.
And at the end he said:
> Also, i'd not mind some test-coverage in sched.git as well.

I far as I know "do not mind" does not mean "must go to" ;-). Also I replied that 
I did not mind either but I do not think that it has much (if anything) to do with
the scheduler.

Anyway. I think I mentioned that I did not mind -mm either. I think it's ready for
the mainline. But if people still strongly feel that it has to be in -mm that's fine.
Lets just do s/Linus/Andrew/ on the first line and move on. But if Linus pulls it now
even better ;-)
  
Andrew, Linus, I'll let you guys decide which tree it needs to go.

Max

  reply	other threads:[~2008-02-10  4:04 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-02-10  3:07 Max Krasnyansky
2008-02-10  3:21 ` Paul Jackson
2008-02-10  3:59   ` Max Krasnyansky [this message]
2008-02-13 10:58     ` Ingo Molnar
2008-02-13 17:18       ` 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=47AE76B8.6060304@qualcomm.com \
    --to=maxk@qualcomm.com \
    --cc=a.p.zijlstra@chello.nl \
    --cc=akpm@linux-foundation.org \
    --cc=gregkh@suse.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=pj@sgi.com \
    --cc=rusty@rustcorp.com.au \
    --cc=torvalds@linux-foundation.org \
    --subject='Re: [git pull] CPU isolation extensions (updated)' \
    /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

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).