From: Joerg Roedel <joro@8bytes.org>
To: Arnd Bergmann <arnd@arndb.de>
Cc: ksummit-discuss@lists.linuxfoundation.org
Subject: Re: [Ksummit-discuss] [CORE TOPIC] Core Kernel support for Compute-Offload Devices
Date: Mon, 3 Aug 2015 18:10:27 +0200 [thread overview]
Message-ID: <20150803161027.GK14980@8bytes.org> (raw)
In-Reply-To: <19442497.AqUzQeifsl@wuerfel>
Hi Arnd,
On Sat, Aug 01, 2015 at 10:46:49PM +0200, Arnd Bergmann wrote:
> 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.
Do you mean that on Cell the offload is synchronous, so that a task that
schedules something to the SPU sleeps until the job there is done?
> 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 think it mostly depends on the use-cases which approach makes more
sense. An HPC environment would certainly want to have full control over
the placement and scheduling on the offload devices. A desktop
environment with typical applications that offload stuff to one or
multiple GPUs through optimized libraries would benefit more from
automatic scheduling and placement.
It is probably good to hear about the use-cases of the different offload
devices to make a good decission here.
Joerg
next prev parent reply other threads:[~2015-08-03 16:10 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
2015-08-03 16:10 ` Joerg Roedel [this message]
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=20150803161027.GK14980@8bytes.org \
--to=joro@8bytes.org \
--cc=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