ksummit.lists.linux.dev archive mirror
 help / color / mirror / Atom feed
From: Arnd Bergmann <arnd@arndb.de>
To: ksummit-discuss@lists.linuxfoundation.org
Subject: Re: [Ksummit-discuss] [CORE TOPIC] Core Kernel support for Compute-Offload Devices
Date: Sat, 01 Aug 2015 22:46:49 +0200	[thread overview]
Message-ID: <19442497.AqUzQeifsl@wuerfel> (raw)
In-Reply-To: <20150730130027.GA14980@8bytes.org>

On Thursday 30 July 2015 15:00:27 Joerg Roedel wrote:
> [
>  The topic is highly technical and could be a tech topic. But it also
>  touches multiple subsystems, so I decided to submit it as a core
>  topic.
> ]
> 
> Across architectures and vendors there are new devices coming up for
> offloading tasks from the CPUs. Most of these devices are capable to
> operate on user address spaces.
> 
> Besides the commonalities there are important differences in the memory
> model these devices offer. Some work only on system RAM, others come
> with their own memory which may or may not be accessible by the CPU.
> 
> I'd like to discuss what support we need in the core kernel for these
> devices. A probably incomplete list of open questions:
> 
> 	(1) Do we need the concept of an off-CPU task in the kernel
> 	    together with a common interface to create and manage them
> 	    and probably a (collection of) batch scheduler(s) for these
> 	    tasks?

I think we did this part right with the Cell SPUs 10 years ago: A
task is a task, and you just switch between running in user mode and
running on the offload engine through some syscall or ioctl.

The part that got us into endless trouble though was trying to
satisfy two opposite requirements: 

a) having the kernel schedule tasks automatically onto the offload
   engines and take care of context switches and placement, so you
   can do multi-user and multi-tasking processing on them.

b) getting most performance out of the of offload engines, by giving
   a single user total control over the placement and no do any
   scheduling in the kernel at all.

I would strongly recommend now that any new interface tries to do
only one of the two models, but does it right.

> I am particularily interested in this topic because on PCIe newer IOMMUs
> are often an integral part in supporting these devices (ARM-SMMUv3,
> Intel VT-d with SVM, AMD IOMMUv2). so that core work here will also
> touch the IOMMU code.
> 
> Probably (uncomplete list of) interested people:
> 
> 	David Woodhouse
> 	Jesse Barnes
> 	Will Deacon
> 	Paul E. McKenney
> 	Rik van Riel
> 	Mel Gorman
> 	Andrea Arcangeli
> 	Christoph Lameter
> 	Jérôme Glisse

Add me in as well,

	Arnd

  parent reply	other threads:[~2015-08-01 20:51 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-07-30 13:00 Joerg Roedel
2015-07-30 13:31 ` David Woodhouse
2015-07-30 13:54   ` Joerg Roedel
2015-07-31 16:34     ` Jerome Glisse
2015-08-03 18:51       ` David Woodhouse
2015-08-03 19:01         ` Jerome Glisse
2015-08-03 19:07           ` Andy Lutomirski
2015-08-03 19:56             ` Jerome Glisse
2015-08-03 21:10           ` Joerg Roedel
2015-08-03 21:12             ` David Woodhouse
2015-08-03 21:31               ` Joerg Roedel
2015-08-03 21:34               ` Jerome Glisse
2015-08-03 21:51                 ` David Woodhouse
2015-08-04 18:11               ` Catalin Marinas
2015-08-03 22:10         ` Benjamin Herrenschmidt
2015-07-30 22:32 ` Benjamin Herrenschmidt
2015-08-01 16:10   ` Joerg Roedel
2015-07-31 14:52 ` Rik van Riel
2015-07-31 16:13   ` Jerome Glisse
2015-08-01 15:57     ` Joerg Roedel
2015-08-01 19:08       ` Jerome Glisse
2015-08-03 16:02         ` Joerg Roedel
2015-08-03 18:28           ` Jerome Glisse
2015-08-01 20:46 ` Arnd Bergmann [this message]
2015-08-03 16:10   ` Joerg Roedel
2015-08-03 19:23     ` Arnd Bergmann
2015-08-04 15:40   ` Christoph Lameter

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=19442497.AqUzQeifsl@wuerfel \
    --to=arnd@arndb.de \
    --cc=ksummit-discuss@lists.linuxfoundation.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