From: Hajime Tazaki <thehajime@gmail.com>
To: johannes@sipsolutions.net
Cc: linux-um@lists.infradead.org, ljs@kernel.org, liam@infradead.org
Subject: Re: [RFC PATCH 0/9] simplified UML/NOMMU approach
Date: Thu, 23 Jul 2026 06:16:59 +0900 [thread overview]
Message-ID: <m24ihq4tdg.wl-thehajime@gmail.com> (raw)
In-Reply-To: <860318a2d3434c35c3bf188776093cb46f2fe152.camel@sipsolutions.net>
Hello,
# +Cc: Lorenzo, Liam,
On Wed, 22 Jul 2026 16:46:31 +0900,
Johannes Berg wrote:
> > um-nommu(seccomp) 3533
> > um-nommu-skas 27844
> > um-nommu-skas(seccomp) 26387
>
> I'm a bit surprised these have such a huge difference, do you see any
> obvious explanation for that?
>
> But I'm also still not really convinced that it matters at all.
I have explained this in the message below:
https://lore.kernel.org/all/m2y0nqwbzg.wl-thehajime@gmail.com/
# was also covered in my netdevconf talk but in a backup slide.
https://speakerdeck.com/thehajime/nommu-uml-netdev-0x1a?slide=28
> > What is your plan for this RFC ?
>
> Well, first I wanted to hear what you think :-)
:)
> > I'm pretty fine with this (skas nommu) mode for nommu UML; it
> > is certainly useful to detect more bugs if it is available in UML.
>
> Yeah, that was mostly my intent - to show a path forward for the nommu
> (kunit) testing in UML, without all the other complexity.
understand.
> > I would also like to ask maintainers if my nommu approach can be an
> > opt-in feature only when specific kernel config is added, probably
> > marking as '(EXPERIMENTAL)' or `if EXPERT` condition, as there is
> > potential benefits (speed, less host process use, etc.).
> >
> > But if you (maintainers) wish and feel this as not an easy option,
> > I can work for it with later patches as an extension.
>
> Personally, I've always mostly thought that there isn't really a good
> use case (or perhaps that you haven't really convinced me of one) that
> actually requires the speed benefit, but I guess I can't really decide
> that by myself. :)
understand too.
actually one of my motivation to give a talk at netdevconf was to
present a use-case of the speed benefit.
but I'd like to rephrase this motivation in a different thread; I wish
to move forward nommu UML as mm folks (cc-ed) might think it's useful.
> > btw, maybe I need a better name for (my) nommu code using different
> > syscall handling, with regard to skas (i.e., separate kernel address
> > space) mode (e.g., CONFIG_UML_NOMMU_SAS (single address space) etc.).
>
> Oh, I didn't even remember now that "skas" was meant to mean "separate
> kernel address space". To me this is all a quirk of history ... we
> probably shouldn't read too much into it now.
Personally, I think skas still does make sense from the host address
space pov; uml kernel and uml-userspace processes are in different
address space.
that's what I meant in CONFIG_UML_NOMMU_SAS in my previous email.
-- Hajime
prev parent reply other threads:[~2026-07-22 21:17 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-20 18:26 [RFC PATCH 0/9] simplified UML/NOMMU approach Johannes Berg
2026-07-20 18:26 ` [RFC PATCH 1/9] x86/um: nommu: elf loader for fdpic Johannes Berg
2026-07-20 18:26 ` [RFC PATCH 2/9] um: decouple MMU specific code from the common part Johannes Berg
2026-07-20 18:26 ` [RFC PATCH 3/9] um: nommu: memory handling Johannes Berg
2026-07-20 18:26 ` [RFC PATCH 4/9] um: change machine name for uname output Johannes Berg
2026-07-20 18:26 ` [RFC PATCH 5/9] x86/um/vdso: nommu: vdso memory update Johannes Berg
2026-07-20 18:26 ` [RFC PATCH 6/9] um: further decouple MMU related code Johannes Berg
2026-07-20 18:26 ` [RFC PATCH 7/9] um: nommu: add SMP futex operations Johannes Berg
2026-07-20 19:06 ` Johannes Berg
2026-07-20 19:10 ` Johannes Berg
2026-07-20 18:26 ` [RFC PATCH 8/9] um: nommu: add userspace runner processes Johannes Berg
2026-07-22 1:30 ` Hajime Tazaki
2026-07-22 12:44 ` Johannes Berg
2026-07-23 4:47 ` Hajime Tazaki
2026-07-23 7:56 ` Johannes Berg
2026-07-20 18:26 ` [RFC PATCH 9/9] um: nommu: plug nommu code into build system Johannes Berg
2026-07-22 0:39 ` [RFC PATCH 0/9] simplified UML/NOMMU approach Hajime Tazaki
2026-07-22 7:46 ` Johannes Berg
2026-07-22 21:16 ` Hajime Tazaki [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=m24ihq4tdg.wl-thehajime@gmail.com \
--to=thehajime@gmail.com \
--cc=johannes@sipsolutions.net \
--cc=liam@infradead.org \
--cc=linux-um@lists.infradead.org \
--cc=ljs@kernel.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 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.