[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH 0/4] unsafe big.LITTLE support

  • To: Julien Grall <julien.grall@xxxxxxx>
  • From: Stefano Stabellini <sstabellini@xxxxxxxxxx>
  • Date: Fri, 16 Feb 2018 14:07:43 -0800 (PST)
  • Authentication-results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=kernel.org
  • Authentication-results: mail.kernel.org; spf=none smtp.mailfrom=sstabellini@xxxxxxxxxx
  • Cc: Stefano Stabellini <sstabellini@xxxxxxxxxx>, xen-devel@xxxxxxxxxxxxx
  • Delivery-date: Fri, 16 Feb 2018 22:08:04 +0000
  • Dmarc-filter: OpenDMARC Filter v1.3.2 mail.kernel.org A05AD2178A
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On Fri, 16 Feb 2018, Julien Grall wrote:
> On 15/02/18 23:16, Stefano Stabellini wrote:
> > Hi all,
> Hi Stefano,
> > This series changes the initialization of two virtual registers to make
> > sure they match the value of the underlying physical cpu.
> > 
> > It also disables cpus different from the boot cpu, unless a newly
> > introduced command line option is specified. In that case, it explains
> > how to setup the system to avoid corruptions, which involves manually
> > specifying the cpu affinity of all domains, because the scheduler still
> > lacks big.LITTLE support.
> On top of this series, I think we want to rework how we read the size of the
> cacheline. At the moment, we only read it on the boot CPU. But they may be
> different on each CPUs.
> So I would replace that variable by reading the cacheline size everytime from
> system registers. This should quicker than trying to read the memory to know
> the cacheline size.
> Note that I suggested this as a small tasks for Outreachy/GSOC.

The suggestion is very good, I'll do it as part of this series.

Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.