From: Tiwei Bie <tiwei.bie@linux.dev>
To: johannes@sipsolutions.net
Cc: richard@nod.at, anton.ivanov@cambridgegreys.com,
linux-um@lists.infradead.org, tiwei.btw@antgroup.com,
tiwei.bie@linux.dev
Subject: Re: [PATCH 9/9] um: Add initial SMP support
Date: Tue, 29 Jul 2025 00:06:51 +0800 [thread overview]
Message-ID: <20250728160651.3268677-1-tiwei.bie@linux.dev> (raw)
In-Reply-To: <80979dce038d684495b77d6a90d19df7a4b94b9c.camel@sipsolutions.net>
On Mon, 28 Jul 2025 15:55:28 +0200, Johannes Berg wrote:
> On Sun, 2025-07-27 at 14:29 +0800, Tiwei Bie wrote:
> >
> > +static void IPI_handler(int cpu, struct uml_pt_regs *regs)
> > +{
> > + struct pt_regs *old_regs = set_irq_regs((struct pt_regs *)regs);
> > + unsigned char c;
> > + int fd;
> > +
> > + irq_enter();
> > +
> > + if (current->mm)
> > + os_alarm_process(current->mm->context.id.pid);
> > +
> > + fd = uml_cpu_data[cpu].ipi_pipe[0];
> > + while (os_read_file(fd, &c, 1) == 1) {
>
> We were discussing the IPI stuff and started thinking maybe an RT signal
> with sigqueue() passing the value to the si_value in SA_SIGINFO data
> would be possible and have less overhead? That way there's nothing on
> the SIGIO path, and you don't need a read() for the type of IPI?
I like this idea. I will give it a try. Thanks!
Regards,
Tiwei
prev parent reply other threads:[~2025-07-28 17:11 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-07-27 6:29 [PATCH 0/9] um: Add SMP support Tiwei Bie
2025-07-27 6:29 ` [PATCH 1/9] um: Stop tracking virtual CPUs via mm_cpumask() Tiwei Bie
2025-07-27 6:29 ` [PATCH 2/9] um: Remove unused cpu_data and current_cpu_data macros Tiwei Bie
2025-07-27 6:29 ` [PATCH 3/9] um: vdso: Implement __vdso_getcpu() via syscall Tiwei Bie
2025-07-27 6:29 ` [PATCH 4/9] um: Preserve errno within signal handler Tiwei Bie
2025-07-27 6:29 ` [PATCH 5/9] um: Turn signals_* into thread-local variables Tiwei Bie
2025-07-27 6:29 ` [PATCH 6/9] um: Determine sleep based on need_resched() Tiwei Bie
2025-07-27 6:29 ` [PATCH 7/9] um: Define timers on a per-CPU basis Tiwei Bie
2025-07-27 6:29 ` [PATCH 8/9] um: Support directing IO signals to calling thread Tiwei Bie
2025-07-27 6:29 ` [PATCH 9/9] um: Add initial SMP support Tiwei Bie
2025-07-28 10:47 ` Johannes Berg
2025-07-28 15:28 ` Randy Dunlap
2025-07-28 16:04 ` Tiwei Bie
2025-07-28 16:27 ` Johannes Berg
2025-07-29 15:06 ` Tiwei Bie
2025-07-29 15:37 ` Johannes Berg
2025-07-30 4:18 ` Tiwei Bie
2025-08-10 4:33 ` Tiwei Bie
2025-07-28 13:55 ` Johannes Berg
2025-07-28 16:06 ` Tiwei Bie [this message]
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=20250728160651.3268677-1-tiwei.bie@linux.dev \
--to=tiwei.bie@linux.dev \
--cc=anton.ivanov@cambridgegreys.com \
--cc=johannes@sipsolutions.net \
--cc=linux-um@lists.infradead.org \
--cc=richard@nod.at \
--cc=tiwei.btw@antgroup.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.