From: Thomas Gleixner <[email protected]>
To: Jens Axboe <[email protected]>, Stefan Metzmacher <[email protected]>,
Linus Torvalds <[email protected]>
Cc: Andy Lutomirski <[email protected]>,
[email protected], [email protected],
[email protected]
Subject: Re: [PATCH v2] io_thread/x86: setup io_threads more like normal user space threads
Date: Thu, 06 May 2021 00:07:43 +0200 [thread overview]
Message-ID: <[email protected]> (raw)
In-Reply-To: <[email protected]>
On Wed, May 05 2021 at 23:57, Thomas Gleixner wrote:
> On Wed, May 05 2021 at 15:24, Jens Axboe wrote:
>> On 5/5/21 5:03 AM, Stefan Metzmacher wrote:
>>> As io_threads are fully set up USER threads it's clearer to
>>> separate the code path from the KTHREAD logic.
>>>
>>> The only remaining difference to user space threads is that
>>> io_threads never return to user space again.
>>> Instead they loop within the given worker function.
>>>
>>> The fact that they never return to user space means they
>>> don't have an user space thread stack. In order to
>>> indicate that to tools like gdb we reset the stack and instruction
>>> pointers to 0.
>>>
>>> This allows gdb attach to user space processes using io-uring,
>>> which like means that they have io_threads, without printing worrying
>>> message like this:
>>>
>>> warning: Selected architecture i386:x86-64 is not compatible with reported target architecture i386
>>>
>>> warning: Architecture rejected target-supplied description
>>>
>>> The output will be something like this:
>>>
>>> (gdb) info threads
>>> Id Target Id Frame
>>> * 1 LWP 4863 "io_uring-cp-for" syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
>>> 2 LWP 4864 "iou-mgr-4863" 0x0000000000000000 in ?? ()
>>> 3 LWP 4865 "iou-wrk-4863" 0x0000000000000000 in ?? ()
>>> (gdb) thread 3
>>> [Switching to thread 3 (LWP 4865)]
>>> #0 0x0000000000000000 in ?? ()
>>> (gdb) bt
>>> #0 0x0000000000000000 in ?? ()
>>> Backtrace stopped: Cannot access memory at address 0x0
>>
>> I have queued this one up in the io_uring branch, also happy to drop it if
>> the x86 folks want to take it instead. Let me know!
>
> I have no objections, but heck what's the rush here?
>
> Waiting a day for the x86 people to respond it not too much asked for
> right?
That said, the proper subject line would be:
x86/process: Setup io_threads ....
Aside of that:
Reviewed-by: Thomas Gleixner <[email protected]>
next prev parent reply other threads:[~2021-05-05 22:07 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-04-11 15:27 [PATCH] io_thread/x86: don't reset 'cs', 'ss', 'ds' and 'es' registers for io_threads Stefan Metzmacher
2021-04-14 21:28 ` Stefan Metzmacher
2021-05-05 11:03 ` [PATCH v2] io_thread/x86: setup io_threads more like normal user space threads Stefan Metzmacher
2021-05-05 21:24 ` Jens Axboe
2021-05-05 21:57 ` Thomas Gleixner
2021-05-05 22:07 ` Thomas Gleixner [this message]
2021-05-05 23:49 ` Jens Axboe
2021-05-06 9:17 ` Thomas Gleixner
2021-05-05 23:35 ` Jens Axboe
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 \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
/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