linux-kernel - Re: using gpu's to accelerate the linux kernel

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <46e286cb-ca1a-4b5a-153f-0e0cade22bb9@metux.net>
Date:   Mon, 21 Aug 2023 16:21:50 +0200
From:   "Enrico Weigelt, metux IT consult" <info@...ux.net>
To:     Raj J Putari <jmaharaj2013@...il.com>,
        LKML <linux-kernel@...r.kernel.org>
Cc:     dri-devel@...ts.freedesktop.org
Subject: Re: using gpu's to accelerate the linux kernel

On 27.04.23 12:51, Raj J Putari wrote:

> id write it but im an amatuer and i dont have time to read the kernel
> source and experiment, we're talking about nvidia and amd video cards
> assisting in processing heavy data.

obviously not w/ NVidia (except for some old, already reverse-engineered
gpus), since Nvidia is doing all they can hiding the necessary specs
to write drivers from us.

Forget about Nvidia. Never ever waste a single penny on that.

> lets say youre compiling a kernel, you can write optimizations into
> the kernel through a cuda module and offload cpu data directly to the
> gpu using opencl or cuda or what amd supplies,

cuda, opencl, etc, are *userland* *library* APIs. They don't work inside
the kernel. One had to write something similar *inside* the kernel
(which is working very differently from userland). Also consider that
the most complex stuff (eg. creating command streams) is done in
userland (eg. mesa's pipe drivers, ...), the kernel is just responsible
for some more lowlevel things like buffer management, modesetting, etc.

If you wanna go that route, you'd have to create something like Mesa's
Gallium inside the kernel. Besides that this is a pretty huge task
(and you'd have to reimplement lots of drivers), you'd also have to
find a way to get a good performance when calling from userland (note
that syscalls, even ioctls, etc, are much more expensive than just
plain library function calls inside the same process). Probably comes
down to using some bytecode (tgsi ?) and loading it somewhat similar
to bpf.

Assuming that's really up and running one day, it indeed could solve
other problems, eg. clear separation between containers and hosts
(for now, containers still needs the userland parts of gpu drivers
for the corresponding host hardware).

But be warned: this is a huge endavour, *a lot* work to do and hard
to get it right.

OTOH, I'm yet sceptical whether there's much practical use cases for
using GPUs by the kernel *itself*. What exactly do you have in mind
here ?

--mtx

-- 
---
Hinweis: unverschlüsselte E-Mails können leicht abgehört und manipuliert
werden ! Für eine vertrauliche Kommunikation senden Sie bitte ihren
GPG/PGP-Schlüssel zu.
---
Enrico Weigelt, metux IT consult
Free software and Linux embedded engineering
info@...ux.net -- +49-151-27565287