This one, I'll swap it out, and you can clip it on yourself, I just need this part.
It's fine, we keep turning it off and on anyways, as we need it.
It's nothing, it's fine, it's fine, it's fine.
This test is fine, can we?
It's fine, it's fine, it's fine, it's fine.
It's fine, it's fine, it's fine, it's fine, it's fine.
It's fine, it's fine, it's fine, it's fine.
It's fine, it's fine, it's fine.
It's fine, it's fine, it's fine, it's fine.
It's fine, it's fine, it's fine.
It's fine, it's fine, it's fine, it's fine.
It's fine, it's fine, it's fine, it's fine, it's fine.
It's fine, it's fine, it's fine, it's fine.
It's fine, it's fine, it's fine, it's fine, it's fine.
It's fine, it's fine, it's fine, it's fine, it's fine, it's fine, it's fine, it's fine, it's fine, it's fine, it's fine, it's fine, it's fine, it's fine, it's fine, it's fine, it's fine.
of only the MMU full code.
Because if you have some MMU specific code inside the content,
you cannot test the code over the UML or the K unit.
So it is very hard to find a MMU specific part with this framework.
So I will give you some of the examples that I
faced during the might of the movement of this headset.
So this is the part set that I propose after finding
a bug in the new MMU code in the memory management system and
the system.
So it was actually the regression of the refructuring the code
with the internal structure of the VMM system, which
is about a map, a map for the user calls refructuring,
and I introduced a disk park which is fixed at this
the proper argument to the particular function code.
So this code was not detected by the K unit K unit
to suite, even though they have a test suite on the test
port over the QM base, QM base testing framework,
with the motor of the processor, the M-solid-5 implementation.
I don't know why this is not detected, this wasn't detected,
but over the use, you may understand that we have been trying
to introduce, we can reproduce this part, when the application
is trying to exit the trying to clean up the memory state state
inside the VMS and subsystem.
So as I mentioned, to alleviate the situation
with the hard to find the bug or the new MMU code in the kernel,
we can utilize the QM or any kind of memory data
to test the new MMM specific code.
But it is also hard to maintain the tool chain for such a
non-popular, I'm popular, I'm popular architecture
or code in federal index kernel.
So this screenshot is the recent patch proposal
of the Linux test project, which
already drops the all of the new MMU test
case on test suite from the upstream three.
So this is because of the one on the reason that this top page
drop is the maintenance bottom of the two chains
for the new MMM architecture.
So I'm going to give you the detailed part
of the other implementation.
So basic things that we try to modify and extend to the existing
memory implementation is to add the config MMM code
and into the K config files.
But this isn't enough for the extension.
So we also introduce the different system
core entry points for the new specically new MMU
mode for the user learning.
Because the nature of the P2S and the system core
interpretation is not familiar with the single other space
in the H of the new MMU kernel.
Because in the new MMM architecture in the Linux kernel,
all the memory address are shared among the multiple processes
and as well as the kernel memory layers.
So there is no page table, I will detail later,
but there is no other translation from the,
so basically, the patch address is identical to the physical address.
So we are trying to explore it, exploit this characteristics
or that now over the new MMU memory management.
And it went into the system calling entry points
for this specific use cases.
The prototype implementation was not implemented
by myself, but the record caller who was working
at IBM in the past was the original contributor
of this patch set.
And the patch set proposal is currently
version 13 already.
It's already spent more than one year, I guess.
And I am still trying to convince the developer
and the maintenance of the user mode in the state.
So I am glad to briefly introduce about what is the new MMM
architecture in the Linux kernel.
So the new MMM architecture was also
initially started at the most system, the same error
over the new MMM origination.
In the late 19th, you see the next project
was introduced to the original code of the new MMM
memory card in the current next set.
And the original target and the motivation
for the using project was to be available for the small
and the embedded devices with the Linux kernel,
without which doesn't have a memory management unit
or MMM in their processor or their microcontroller.
So the main focus is only for the embedded device
at the error, but now it is still useful.
And our interpretation about this new MMM architecture
is also useful for the batchization purpose
if the guest machine only has a single process, for example.
We don't have to have a page management or process
management between the, instead of memory management
for the system.
So we can utilize the set here, simplify the way
in very, very memory management function
in a very specialized device case.
So we are following this concept in the new MMM
and the extension.
As I mentioned before, there is only single other space
available in the memory layer.
So the batch error address is already always identical
to the physical address.
Now there are no page tables, which means
that the multiple processes share the same other space,
which means that there are no memory protection
among the multiple processes.
And also we also have to follow the way
that the binary loader of the executable,
other space executable should be built
with the position independent for,
because the location for the binary loader binary
is not, we cannot use the absolute other
source for that location to be loaded.
So it should be built with the PIC or PIE option
for the object.
And this is also generally general limitation
for the new MMM, the extension in the Linux scanner.
But we cannot utilize the forks system call,
instead we should use the forks' call, instead.
And also MLM system call has a little solution.
On the option availability for the system call.
So I'm also going to introduce about the most
significant differences between them.
The original UMA implementation, implementation,
which is about the different system call entry points.
So in this slide, I'm showing the sequence of the how
the difference is called entry points works.
So our current implementation is initially trying
to install the second filter for the interested systems
interested in Cisco.
But we are only installing the filter
for the memory location with other instruction points,
the other instruction point.
And then the user space invoke the Cisco interaction.
The host scanner, ladies, ladies, ladies, the signal,
which is success, based on the second filter installed
in the first steps.
And after the signal, 100 is called,
this is not by our implementation.
This is just setting the next Cisco entry point,
which is the actual Cisco entry point
of the new memory economy.
And the set, this address, as in the instruction point,
which is a better one, which is configured inside the signal,
100.
And also jump into the Cisco entry.
Actually, this is going to the point after that.
And the same one, the several registers,
which is required to execute the corner code after the Cisco
entry point.
And also, manipulate the current set, select,
and select point-time in the current site.
And also, they call the Cisco table entry,
based on the number of the system called the Cisco number.
And after that jump back to the user space
by lowering back to the registered state
and configuring the entry and the entrance of the entry point.
So green part from step one to step three
can be replaced with the binary transition,
binary directly writing, instead of the second
fleet of signal-based trap for the system called interpolation.
So as I mentioned, so no MMI architecture
has the country in the next several limitations,
as I mentioned.
The B4K is only available for system code
for the no MMI scanner, because copy-on-light
is not available in this moment.
And also, the B4K in the B4K Cisco,
the parent process has to wait on the block
until the challenge for children with the grizzette,
or a child called a child in box exit Cisco.
So which means that you can run maybe shell program using
but you cannot run the parallelized mechanism
like a patch demo, or engine usage
is the most preferred system code in the single process
and from the single parent process.
And without any exact system code,
in order to parallelize the CPU and the CPU process
with the incoming requests.
This is not available in this case
for the no MMI scanner.
And also, PIE binary is also requirement
as the limitation of the memory layout.
And also process shared multiple processes,
processes shared the same other space,
which means that there are no memory protection
between the multiple processes.
So we integrated this connection to the current and extension.
We integrated the Linux distribution based on the other pi
and Linux, because the other pi and Linux is useful
to use the PIE binary for this specific application.
And in addition to that, we need to have no MMI hardware
where you have space application.
And the busy box and the module we see has an option,
which is not default, which is disabled by default
in the RFI Linux, but we will run
to offer the alternate option of these packages
and to utilize with no MMI scanner
in the RFI Linux distribution.
So we plan to upstream this package as well
after the upstream process of the scanner itself is done.
This is the demo of the shared session.
It is very typical in XCOMON grind, showing
the process disorder processes.
I will skip this part.
So I will give you some of the showcase
over the other part of it.
So as I mentioned, one of the motivation for this work
is to promote an improved session, the testing
knowing when we're coding the Linux column.
So these are the two examples that I faced during the development.
The first part is the one that I showed in the previous slide,
and which is about a regression,
the regression on the map protection.
And the second one is the small descent one,
which was the previous one.
So as December I guess, in the 6.19 column,
which is still this candidate I agree,
there was also a regression on the only
new MMU scanner in the MMM subsystem,
which introduced the detroxiation
when the user space triggered the whole out-of-memory situation.
Where it's my castle time.
So the left part demonstrate the detroxiation
when you use the space trying to allocate the memory
as much as possible until the end of the loop
is the loop is ended.
And in this case, we cannot let down from this application
and the time to kill from the external process,
because this is the only, for this case,
we are using the other more Linux,
but in the actual no MMM platform,
like Motorola processor,
it will be hand-hawable,
and we cannot control over the input from the external processes.
But with the fix,
with the fix in the right side,
it will also demonstrate the proper handling
after the auto-memory situation.
With the proper messages of the from the counter-site.
So another use case is also transparent use
pages with the K-ELETE framework,
but we just need to add additional argument
of the K-ELETE framework to the K-ELETE command right.
And we are testing all the units implemented
with this K-ELETE framework, K-ELETE configuration.
And also, I will give you a brief,
a home on standby for the cellular benchmark.
The upper part is the benchmark
with the measuring the system code latency.
With we had a five different configuration,
native means the bear-maker, Linux-Carner,
the X-Carner.
The UM is the original UMM implementation
with the P3S-S-COF mechanism.
MMM-S is the UMM, with the second filter,
with the MMM enabled.
No MMM, with S is the,
no MMM, our extension is the second filter.
And the no MMM is that is the,
yet another binary,
the writing-based system code suite.
So as you can see,
when we should compare with only this part and this part,
which is different, only difference between those two
are the, whether MMM is enabled or not.
And we can see the mostly 10 times faster
for the no MMM part,
which is mostly because of the simplicity
of the no MMM, no MMM calendar.
And the MMM full kernel has a desperate moment,
but they had, they had the generality
for the application support.
And the bottom part is also using the same five configuration,
with the LM-Benz suite and also iPad V.
And the trend for the performance number is almost similar
to what get the PIDs benchmark does.
So I'm sharing some of the discussion in the mailing list.
And the most of the kernel,
the beta-quarly cognites that this extension series
used through to test the no MMM code,
is the K unit.
And somebody also expressed the interest
on the head, the interest on the 20-utiles,
if this is a pristine thing in the future.
And the speed up, as I mentioned in the previous slide,
is coming from the simplicity of the no MMM calendar,
but this is at the cost of the lack of the generality
for the application support, because of the severality
score restriction, as I explained.
And I, so for the next step,
is I will propose this part set
is that Qajan 14 proposal.
And also more wrong attempt on contribution.
We focused the selection, the limitation is very severe,
or severe, critical for our understanding,
but we can also consider the alternate fork implementation.
So the micro fork is essentially proposed
in the academic society.
And this doesn't require the copyright functionality
from the hardware, but they usually
defined mechanism to offer the same functionality
of the fork instead of the before, which
might be used through for this case in the future.
So that's almost it for my talk.
So I introduced our extension, but the no MMM
makes more introduction to the user mode relapse.
And to make testing easier for the no MMM recording
the Linux 3.
And the speed up is optional, and the bonus point
for the implementation, but this is at the cost of the list
in this generality.
And the value of 14 should be very skipped,
very slightly after going back to my home.
So thank you for all this thing.
And I'm happy to take any questions you have.
Thank you for the nice work.
My question is that you use the alpine based
mussel tool chain, with busy box will build root,
where there is an option just to compile.
And this was 64 bit only for x86.
Only for x86.
I think only this file also there
is a 32 bit option.
And a lot of people are trying to boot Linux
on ESP32 or Raspberry Pi P code.
So they also make a lot of use there.
So maybe we can collaborate on this effort to get it in such a way.
So it's a continuation, like podmon containers.
We work on kind of this MMM disabled.
I'm sorry, I didn't get to go across that.
It's continuation, like podmon containers,
working on Linux kernel when MMM is deactivated.
Like this, no MMM, I agree.
I'm not sure if this is ready to run to our extension,
but this is the very, this is very useful
specific implementation.
It doesn't, it can be useful for the darling content
on top of this email, this application.
But I don't know, maybe I will ask you later for more detail.
I don't understand what's going to be the question, I'm sorry.
Thank you.
In your comparison slides, where you
just compared the speed of UML, MMU, UML, no MMU,
and just UML.
So what's the difference between just UML and UML, MMU?
I didn't get that.
I didn't hear the last part of your question.
So what's the difference between normal UML and UML, MMU?
OK.
So the biggest difference is that the MMM,
the relation part of the original UML implementation.
We don't have a page table, so we don't have to emulate
the page for, for example,
and also, it doesn't have to implement the page
in switching page table between the multiple UMLs,
that's the supposed to be.
That will be the very, primarily difference between the UML.
Thank you.
OK, thank you.
Thank you.
Thank you very much.
Bye.
So...