All of lore.kernel.org
 help / color / mirror / Atom feed
From: Srikar Dronamraju <srikar@linux.vnet.ibm.com>
To: peterz@infradead.org
Cc: Michael Ellerman <mpe@ellerman.id.au>,
	Ingo Molnar <mingo@kernel.org>,
	LKML <linux-kernel@vger.kernel.org>,
	Mel Gorman <mgorman@techsingularity.net>,
	Rik van Riel <riel@surriel.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Valentin Schneider <valentin.schneider@arm.com>,
	Vincent Guittot <vincent.guittot@linaro.org>,
	Dietmar Eggemann <dietmar.eggemann@arm.com>,
	linuxppc-dev <linuxppc-dev@lists.ozlabs.org>,
	Michael Neuling <mikey@neuling.org>,
	Gautham R Shenoy <ego@linux.vnet.ibm.com>,
	Vaidyanathan Srinivasan <svaidy@linux.ibm.com>
Subject: Re: [PATCH 1/2] sched/topology: Allow archs to override cpu_smt_mask
Date: Thu, 6 Aug 2020 19:39:55 +0530	[thread overview]
Message-ID: <20200806140955.GC31068@linux.vnet.ibm.com> (raw)
In-Reply-To: <20200806131547.GC2674@hirez.programming.kicks-ass.net>

* peterz@infradead.org <peterz@infradead.org> [2020-08-06 15:15:47]:

> > But my understanding is most LPARs don't get migrated back and forth,
> > they'll start life on a P8 and only get migrated to a P9 once when the
> > customer gets a P9. They might then run for a long time (months to
> > years) on the P9 in P8 compat mode, not because they ever want to
> > migrate back to a real P8, but because the software in the LPAR is still
> > expecting to be on a P8.
> > 
> > I'm not a real expert on all the Enterprisey stuff though, so someone
> > else might be able to give us a better picture.
> > 
> > But the point of mentioning the migration stuff was mainly just to
> > explain why we feel we need to present SMT8 to userspace even on P9.
> 
> OK, fair enough. The patch wasn't particularly onerous, I was just
> wondering why etc..
> 
> The case of starting on a P8 and being migrated to a P9 makes sense to
> me; in that case you'd like to rebuild your sched domains, but can't go
> about changing user visible topolofy information.
> 
> I suppose:
> 
> Acked-by; Peter Zijlstra (Intel) <peterz@infradead.org>
> 
> An updated Changelog that recaps some of this discussion might also be
> nice.

Okay, will surely do the needful.

-- 
Thanks and Regards
Srikar Dronamraju

WARNING: multiple messages have this Message-ID (diff)
From: Srikar Dronamraju <srikar@linux.vnet.ibm.com>
To: peterz@infradead.org
Cc: Gautham R Shenoy <ego@linux.vnet.ibm.com>,
	Michael Neuling <mikey@neuling.org>,
	Vincent Guittot <vincent.guittot@linaro.org>,
	Rik van Riel <riel@surriel.com>,
	linuxppc-dev <linuxppc-dev@lists.ozlabs.org>,
	LKML <linux-kernel@vger.kernel.org>,
	Valentin Schneider <valentin.schneider@arm.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Mel Gorman <mgorman@techsingularity.net>,
	Ingo Molnar <mingo@kernel.org>,
	Dietmar Eggemann <dietmar.eggemann@arm.com>
Subject: Re: [PATCH 1/2] sched/topology: Allow archs to override cpu_smt_mask
Date: Thu, 6 Aug 2020 19:39:55 +0530	[thread overview]
Message-ID: <20200806140955.GC31068@linux.vnet.ibm.com> (raw)
In-Reply-To: <20200806131547.GC2674@hirez.programming.kicks-ass.net>

* peterz@infradead.org <peterz@infradead.org> [2020-08-06 15:15:47]:

> > But my understanding is most LPARs don't get migrated back and forth,
> > they'll start life on a P8 and only get migrated to a P9 once when the
> > customer gets a P9. They might then run for a long time (months to
> > years) on the P9 in P8 compat mode, not because they ever want to
> > migrate back to a real P8, but because the software in the LPAR is still
> > expecting to be on a P8.
> > 
> > I'm not a real expert on all the Enterprisey stuff though, so someone
> > else might be able to give us a better picture.
> > 
> > But the point of mentioning the migration stuff was mainly just to
> > explain why we feel we need to present SMT8 to userspace even on P9.
> 
> OK, fair enough. The patch wasn't particularly onerous, I was just
> wondering why etc..
> 
> The case of starting on a P8 and being migrated to a P9 makes sense to
> me; in that case you'd like to rebuild your sched domains, but can't go
> about changing user visible topolofy information.
> 
> I suppose:
> 
> Acked-by; Peter Zijlstra (Intel) <peterz@infradead.org>
> 
> An updated Changelog that recaps some of this discussion might also be
> nice.

Okay, will surely do the needful.

-- 
Thanks and Regards
Srikar Dronamraju

  reply	other threads:[~2020-08-06 16:43 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-08-04  3:33 [PATCH 1/2] sched/topology: Allow archs to override cpu_smt_mask Srikar Dronamraju
2020-08-04  3:33 ` Srikar Dronamraju
2020-08-04  3:33 ` [PATCH 2/2] powerpc/topology: Override cpu_smt_mask Srikar Dronamraju
2020-08-04  3:33   ` Srikar Dronamraju
2020-08-04 10:46   ` peterz
2020-08-04 10:46     ` peterz
2020-08-04 11:02     ` Valentin Schneider
2020-08-04 11:02       ` Valentin Schneider
2020-08-04 10:45 ` [PATCH 1/2] sched/topology: Allow archs to override cpu_smt_mask peterz
2020-08-04 10:45   ` peterz
2020-08-04 12:10   ` Srikar Dronamraju
2020-08-04 12:10     ` Srikar Dronamraju
2020-08-04 12:47     ` peterz
2020-08-04 12:47       ` peterz
2020-08-06  5:32       ` Michael Ellerman
2020-08-06  5:32         ` Michael Ellerman
2020-08-06  8:54         ` peterz
2020-08-06  8:54           ` peterz
2020-08-06 12:25           ` Michael Ellerman
2020-08-06 12:25             ` Michael Ellerman
2020-08-06 13:15             ` peterz
2020-08-06 13:15               ` peterz
2020-08-06 14:09               ` Srikar Dronamraju [this message]
2020-08-06 14:09                 ` Srikar Dronamraju
2020-08-06 12:53           ` Srikar Dronamraju
2020-08-06 12:53             ` Srikar Dronamraju

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=20200806140955.GC31068@linux.vnet.ibm.com \
    --to=srikar@linux.vnet.ibm.com \
    --cc=dietmar.eggemann@arm.com \
    --cc=ego@linux.vnet.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=mgorman@techsingularity.net \
    --cc=mikey@neuling.org \
    --cc=mingo@kernel.org \
    --cc=mpe@ellerman.id.au \
    --cc=peterz@infradead.org \
    --cc=riel@surriel.com \
    --cc=svaidy@linux.ibm.com \
    --cc=tglx@linutronix.de \
    --cc=valentin.schneider@arm.com \
    --cc=vincent.guittot@linaro.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 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.