WEBVTT

00:00.000 --> 00:15.000
This one, I'll swap it out, and you can clip it on yourself, I just need this part.

00:15.000 --> 00:30.000
It's fine, we keep turning it off and on anyways, as we need it.

00:30.000 --> 00:40.000
It's nothing, it's fine, it's fine, it's fine.

00:40.000 --> 00:50.000
This test is fine, can we?

01:10.000 --> 01:32.000
It's fine, it's fine, it's fine, it's fine.

01:32.000 --> 01:42.000
It's fine, it's fine, it's fine, it's fine, it's fine.

01:42.000 --> 01:52.000
It's fine, it's fine, it's fine, it's fine.

02:12.000 --> 02:22.000
It's fine, it's fine, it's fine.

02:22.000 --> 02:32.000
It's fine, it's fine, it's fine.

02:52.000 --> 03:02.000
It's fine, it's fine, it's fine.

03:02.000 --> 03:17.000
It's fine, it's fine, it's fine, it's fine.

03:17.000 --> 03:27.000
It's fine, it's fine, it's fine.

03:47.000 --> 03:57.000
It's fine, it's fine, it's fine, it's fine.

03:57.000 --> 04:12.000
It's fine, it's fine, it's fine, it's fine.

04:12.000 --> 04:27.000
It's fine, it's fine, it's fine, it's fine.

04:27.000 --> 04:42.000
It's fine, it's fine, it's fine, it's fine.

04:42.000 --> 04:57.000
It's fine, it's fine, it's fine, it's fine, it's fine.

04:57.000 --> 05:12.000
It's fine, it's fine, it's fine, it's fine.

05:12.000 --> 05:27.000
It's fine, it's fine, it's fine, it's fine, it's fine.

05:27.000 --> 05:41.000
It's fine, it's fine, it's fine, it's fine, it's fine.

05:57.000 --> 06:22.000
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.

06:22.000 --> 06:25.560
of only the MMU full code.

06:25.560 --> 06:30.400
Because if you have some MMU specific code inside the content,

06:30.400 --> 06:36.880
you cannot test the code over the UML or the K unit.

06:36.880 --> 06:45.040
So it is very hard to find a MMU specific part with this framework.

06:45.040 --> 06:46.960
So I will give you some of the examples that I

06:46.960 --> 06:51.120
faced during the might of the movement of this headset.

06:51.120 --> 06:55.360
So this is the part set that I propose after finding

06:55.360 --> 06:59.760
a bug in the new MMU code in the memory management system and

06:59.760 --> 07:01.280
the system.

07:01.280 --> 07:04.920
So it was actually the regression of the refructuring the code

07:04.920 --> 07:11.280
with the internal structure of the VMM system, which

07:11.280 --> 07:16.680
is about a map, a map for the user calls refructuring,

07:16.680 --> 07:21.560
and I introduced a disk park which is fixed at this

07:21.560 --> 07:26.840
the proper argument to the particular function code.

07:26.840 --> 07:32.920
So this code was not detected by the K unit K unit

07:32.920 --> 07:38.040
to suite, even though they have a test suite on the test

07:38.040 --> 07:42.680
port over the QM base, QM base testing framework,

07:42.680 --> 07:47.640
with the motor of the processor, the M-solid-5 implementation.

07:47.640 --> 07:50.280
I don't know why this is not detected, this wasn't detected,

07:50.280 --> 07:54.520
but over the use, you may understand that we have been trying

07:54.520 --> 08:02.920
to introduce, we can reproduce this part, when the application

08:02.920 --> 08:08.560
is trying to exit the trying to clean up the memory state state

08:08.560 --> 08:12.560
inside the VMS and subsystem.

08:12.560 --> 08:16.080
So as I mentioned, to alleviate the situation

08:16.080 --> 08:20.640
with the hard to find the bug or the new MMU code in the kernel,

08:20.640 --> 08:24.080
we can utilize the QM or any kind of memory data

08:24.080 --> 08:27.080
to test the new MMM specific code.

08:27.080 --> 08:32.520
But it is also hard to maintain the tool chain for such a

08:32.520 --> 08:37.040
non-popular, I'm popular, I'm popular architecture

08:37.040 --> 08:39.560
or code in federal index kernel.

08:39.560 --> 08:46.520
So this screenshot is the recent patch proposal

08:46.520 --> 08:51.000
of the Linux test project, which

08:51.000 --> 08:55.240
already drops the all of the new MMU test

08:55.240 --> 08:58.840
case on test suite from the upstream three.

08:58.840 --> 09:03.800
So this is because of the one on the reason that this top page

09:03.800 --> 09:10.040
drop is the maintenance bottom of the two chains

09:10.040 --> 09:11.400
for the new MMM architecture.

09:14.920 --> 09:19.000
So I'm going to give you the detailed part

09:19.000 --> 09:21.520
of the other implementation.

09:21.520 --> 09:29.120
So basic things that we try to modify and extend to the existing

09:29.120 --> 09:33.840
memory implementation is to add the config MMM code

09:33.840 --> 09:36.400
and into the K config files.

09:36.400 --> 09:41.760
But this isn't enough for the extension.

09:41.760 --> 09:44.040
So we also introduce the different system

09:44.040 --> 09:48.160
core entry points for the new specically new MMU

09:48.160 --> 09:50.480
mode for the user learning.

09:50.480 --> 09:55.680
Because the nature of the P2S and the system core

09:55.680 --> 09:58.680
interpretation is not familiar with the single other space

09:58.680 --> 10:00.920
in the H of the new MMU kernel.

10:00.920 --> 10:04.480
Because in the new MMM architecture in the Linux kernel,

10:04.480 --> 10:08.360
all the memory address are shared among the multiple processes

10:08.360 --> 10:11.920
and as well as the kernel memory layers.

10:11.920 --> 10:15.160
So there is no page table, I will detail later,

10:15.160 --> 10:19.000
but there is no other translation from the,

10:19.000 --> 10:23.320
so basically, the patch address is identical to the physical address.

10:23.320 --> 10:27.720
So we are trying to explore it, exploit this characteristics

10:27.720 --> 10:31.520
or that now over the new MMU memory management.

10:31.520 --> 10:34.200
And it went into the system calling entry points

10:34.200 --> 10:37.000
for this specific use cases.

10:37.000 --> 10:39.480
The prototype implementation was not implemented

10:39.480 --> 10:45.000
by myself, but the record caller who was working

10:45.000 --> 10:48.600
at IBM in the past was the original contributor

10:48.600 --> 10:51.480
of this patch set.

10:51.480 --> 10:53.800
And the patch set proposal is currently

10:53.800 --> 10:55.720
version 13 already.

10:55.720 --> 10:59.920
It's already spent more than one year, I guess.

10:59.920 --> 11:02.680
And I am still trying to convince the developer

11:02.680 --> 11:07.920
and the maintenance of the user mode in the state.

11:07.920 --> 11:11.880
So I am glad to briefly introduce about what is the new MMM

11:11.880 --> 11:14.120
architecture in the Linux kernel.

11:14.120 --> 11:17.080
So the new MMM architecture was also

11:17.080 --> 11:21.080
initially started at the most system, the same error

11:21.080 --> 11:24.480
over the new MMM origination.

11:24.480 --> 11:27.640
In the late 19th, you see the next project

11:27.640 --> 11:30.640
was introduced to the original code of the new MMM

11:30.640 --> 11:34.280
memory card in the current next set.

11:34.280 --> 11:37.720
And the original target and the motivation

11:37.720 --> 11:45.720
for the using project was to be available for the small

11:45.720 --> 11:48.560
and the embedded devices with the Linux kernel,

11:48.560 --> 11:53.120
without which doesn't have a memory management unit

11:53.120 --> 11:58.720
or MMM in their processor or their microcontroller.

11:58.720 --> 12:02.720
So the main focus is only for the embedded device

12:02.720 --> 12:08.760
at the error, but now it is still useful.

12:08.760 --> 12:11.920
And our interpretation about this new MMM architecture

12:11.920 --> 12:14.800
is also useful for the batchization purpose

12:14.800 --> 12:19.600
if the guest machine only has a single process, for example.

12:19.600 --> 12:23.360
We don't have to have a page management or process

12:23.360 --> 12:26.400
management between the, instead of memory management

12:26.400 --> 12:27.160
for the system.

12:27.160 --> 12:30.560
So we can utilize the set here, simplify the way

12:30.560 --> 12:35.160
in very, very memory management function

12:35.160 --> 12:36.960
in a very specialized device case.

12:36.960 --> 12:46.160
So we are following this concept in the new MMM

12:46.160 --> 12:47.840
and the extension.

12:47.840 --> 12:50.800
As I mentioned before, there is only single other space

12:50.800 --> 12:53.400
available in the memory layer.

12:53.400 --> 12:57.640
So the batch error address is already always identical

12:57.640 --> 12:59.640
to the physical address.

12:59.640 --> 13:02.040
Now there are no page tables, which means

13:02.040 --> 13:05.520
that the multiple processes share the same other space,

13:05.520 --> 13:08.160
which means that there are no memory protection

13:08.160 --> 13:11.520
among the multiple processes.

13:11.520 --> 13:15.280
And also we also have to follow the way

13:15.280 --> 13:18.080
that the binary loader of the executable,

13:18.080 --> 13:21.480
other space executable should be built

13:21.480 --> 13:23.720
with the position independent for,

13:23.720 --> 13:28.680
because the location for the binary loader binary

13:28.680 --> 13:31.880
is not, we cannot use the absolute other

13:31.880 --> 13:34.400
source for that location to be loaded.

13:34.400 --> 13:38.000
So it should be built with the PIC or PIE option

13:38.000 --> 13:41.640
for the object.

13:41.640 --> 13:45.080
And this is also generally general limitation

13:45.080 --> 13:48.280
for the new MMM, the extension in the Linux scanner.

13:48.280 --> 13:51.160
But we cannot utilize the forks system call,

13:51.160 --> 13:54.880
instead we should use the forks' call, instead.

13:54.880 --> 13:58.560
And also MLM system call has a little solution.

13:58.560 --> 14:03.560
On the option availability for the system call.

14:06.840 --> 14:12.120
So I'm also going to introduce about the most

14:12.120 --> 14:14.880
significant differences between them.

14:14.880 --> 14:17.960
The original UMA implementation, implementation,

14:17.960 --> 14:22.360
which is about the different system call entry points.

14:22.360 --> 14:26.960
So in this slide, I'm showing the sequence of the how

14:27.720 --> 14:30.800
the difference is called entry points works.

14:30.800 --> 14:34.960
So our current implementation is initially trying

14:34.960 --> 14:39.960
to install the second filter for the interested systems

14:39.960 --> 14:42.720
interested in Cisco.

14:42.720 --> 14:45.440
But we are only installing the filter

14:45.440 --> 14:50.440
for the memory location with other instruction points,

14:50.440 --> 14:54.240
the other instruction point.

14:54.240 --> 14:58.640
And then the user space invoke the Cisco interaction.

14:58.640 --> 15:02.360
The host scanner, ladies, ladies, ladies, the signal,

15:02.360 --> 15:06.440
which is success, based on the second filter installed

15:06.440 --> 15:08.920
in the first steps.

15:08.920 --> 15:12.560
And after the signal, 100 is called,

15:12.560 --> 15:15.520
this is not by our implementation.

15:15.520 --> 15:20.520
This is just setting the next Cisco entry point,

15:20.520 --> 15:23.160
which is the actual Cisco entry point

15:23.160 --> 15:25.040
of the new memory economy.

15:25.040 --> 15:30.400
And the set, this address, as in the instruction point,

15:30.400 --> 15:34.160
which is a better one, which is configured inside the signal,

15:34.160 --> 15:36.280
100.

15:36.280 --> 15:38.520
And also jump into the Cisco entry.

15:38.520 --> 15:41.040
Actually, this is going to the point after that.

15:41.040 --> 15:44.480
And the same one, the several registers,

15:44.480 --> 15:48.920
which is required to execute the corner code after the Cisco

15:48.920 --> 15:49.720
entry point.

15:49.720 --> 15:52.080
And also, manipulate the current set, select,

15:52.080 --> 15:55.640
and select point-time in the current site.

15:55.640 --> 16:01.320
And also, they call the Cisco table entry,

16:01.320 --> 16:04.600
based on the number of the system called the Cisco number.

16:04.600 --> 16:06.640
And after that jump back to the user space

16:06.640 --> 16:11.240
by lowering back to the registered state

16:11.240 --> 16:16.120
and configuring the entry and the entrance of the entry point.

16:16.120 --> 16:19.840
So green part from step one to step three

16:19.840 --> 16:23.040
can be replaced with the binary transition,

16:23.040 --> 16:25.920
binary directly writing, instead of the second

16:25.920 --> 16:34.480
fleet of signal-based trap for the system called interpolation.

16:34.480 --> 16:37.760
So as I mentioned, so no MMI architecture

16:37.760 --> 16:41.880
has the country in the next several limitations,

16:41.880 --> 16:43.240
as I mentioned.

16:43.240 --> 16:46.200
The B4K is only available for system code

16:46.200 --> 16:50.360
for the no MMI scanner, because copy-on-light

16:50.360 --> 16:53.960
is not available in this moment.

16:53.960 --> 16:58.120
And also, the B4K in the B4K Cisco,

16:58.120 --> 17:01.000
the parent process has to wait on the block

17:01.000 --> 17:04.640
until the challenge for children with the grizzette,

17:04.640 --> 17:11.480
or a child called a child in box exit Cisco.

17:11.480 --> 17:15.480
So which means that you can run maybe shell program using

17:15.480 --> 17:19.920
but you cannot run the parallelized mechanism

17:19.920 --> 17:23.280
like a patch demo, or engine usage

17:23.280 --> 17:25.960
is the most preferred system code in the single process

17:25.960 --> 17:28.160
and from the single parent process.

17:28.160 --> 17:30.280
And without any exact system code,

17:30.280 --> 17:34.440
in order to parallelize the CPU and the CPU process

17:34.440 --> 17:37.040
with the incoming requests.

17:37.040 --> 17:40.440
This is not available in this case

17:40.440 --> 17:43.520
for the no MMI scanner.

17:43.520 --> 17:47.440
And also, PIE binary is also requirement

17:47.440 --> 17:52.920
as the limitation of the memory layout.

17:52.920 --> 17:56.520
And also process shared multiple processes,

17:56.520 --> 17:59.280
processes shared the same other space,

17:59.280 --> 18:01.720
which means that there are no memory protection

18:01.720 --> 18:03.520
between the multiple processes.

18:03.520 --> 18:11.440
So we integrated this connection to the current and extension.

18:11.440 --> 18:16.440
We integrated the Linux distribution based on the other pi

18:16.440 --> 18:19.920
and Linux, because the other pi and Linux is useful

18:19.920 --> 18:25.920
to use the PIE binary for this specific application.

18:25.920 --> 18:31.760
And in addition to that, we need to have no MMI hardware

18:31.760 --> 18:35.680
where you have space application.

18:35.680 --> 18:40.040
And the busy box and the module we see has an option,

18:40.040 --> 18:43.960
which is not default, which is disabled by default

18:43.960 --> 18:49.760
in the RFI Linux, but we will run

18:49.760 --> 18:54.000
to offer the alternate option of these packages

18:54.000 --> 18:58.760
and to utilize with no MMI scanner

18:58.760 --> 19:01.520
in the RFI Linux distribution.

19:01.520 --> 19:03.560
So we plan to upstream this package as well

19:03.560 --> 19:09.080
after the upstream process of the scanner itself is done.

19:15.720 --> 19:17.760
This is the demo of the shared session.

19:24.760 --> 19:30.280
It is very typical in XCOMON grind, showing

19:30.280 --> 19:34.360
the process disorder processes.

19:34.360 --> 19:37.360
I will skip this part.

19:37.360 --> 19:40.040
So I will give you some of the showcase

19:40.040 --> 19:41.920
over the other part of it.

19:41.920 --> 19:45.280
So as I mentioned, one of the motivation for this work

19:45.280 --> 19:49.440
is to promote an improved session, the testing

19:49.440 --> 19:52.400
knowing when we're coding the Linux column.

19:52.400 --> 19:57.240
So these are the two examples that I faced during the development.

19:57.240 --> 20:00.720
The first part is the one that I showed in the previous slide,

20:00.720 --> 20:04.040
and which is about a regression,

20:04.040 --> 20:07.240
the regression on the map protection.

20:07.240 --> 20:09.560
And the second one is the small descent one,

20:09.560 --> 20:11.720
which was the previous one.

20:11.720 --> 20:19.720
So as December I guess, in the 6.19 column,

20:19.720 --> 20:23.440
which is still this candidate I agree,

20:23.440 --> 20:26.440
there was also a regression on the only

20:26.440 --> 20:31.440
new MMU scanner in the MMM subsystem,

20:31.440 --> 20:34.400
which introduced the detroxiation

20:34.400 --> 20:39.400
when the user space triggered the whole out-of-memory situation.

20:41.800 --> 20:44.120
Where it's my castle time.

20:44.120 --> 20:47.800
So the left part demonstrate the detroxiation

20:47.800 --> 20:51.320
when you use the space trying to allocate the memory

20:51.320 --> 20:54.160
as much as possible until the end of the loop

20:54.160 --> 20:58.320
is the loop is ended.

20:58.320 --> 21:03.840
And in this case, we cannot let down from this application

21:03.840 --> 21:08.160
and the time to kill from the external process,

21:08.160 --> 21:12.480
because this is the only, for this case,

21:12.480 --> 21:14.520
we are using the other more Linux,

21:14.520 --> 21:17.960
but in the actual no MMM platform,

21:17.960 --> 21:19.520
like Motorola processor,

21:19.800 --> 21:23.240
it will be hand-hawable,

21:23.240 --> 21:28.240
and we cannot control over the input from the external processes.

21:32.640 --> 21:34.960
But with the fix,

21:38.000 --> 21:41.200
with the fix in the right side,

21:41.200 --> 21:47.840
it will also demonstrate the proper handling

21:47.840 --> 21:50.120
after the auto-memory situation.

21:57.120 --> 22:01.960
With the proper messages of the from the counter-site.

22:06.840 --> 22:10.280
So another use case is also transparent use

22:10.280 --> 22:12.480
pages with the K-ELETE framework,

22:12.480 --> 22:17.720
but we just need to add additional argument

22:17.720 --> 22:22.720
of the K-ELETE framework to the K-ELETE command right.

22:25.440 --> 22:29.560
And we are testing all the units implemented

22:29.560 --> 22:32.960
with this K-ELETE framework, K-ELETE configuration.

22:35.200 --> 22:36.840
And also, I will give you a brief,

22:36.840 --> 22:39.800
a home on standby for the cellular benchmark.

22:39.800 --> 22:42.160
The upper part is the benchmark

22:42.160 --> 22:45.400
with the measuring the system code latency.

22:45.400 --> 22:49.440
With we had a five different configuration,

22:49.440 --> 22:53.040
native means the bear-maker, Linux-Carner,

22:53.040 --> 22:53.880
the X-Carner.

22:53.880 --> 22:57.000
The UM is the original UMM implementation

22:57.000 --> 22:59.600
with the P3S-S-COF mechanism.

22:59.600 --> 23:03.960
MMM-S is the UMM, with the second filter,

23:03.960 --> 23:06.200
with the MMM enabled.

23:06.200 --> 23:08.600
No MMM, with S is the,

23:08.600 --> 23:11.400
no MMM, our extension is the second filter.

23:11.400 --> 23:14.000
And the no MMM is that is the,

23:14.000 --> 23:16.840
yet another binary,

23:16.840 --> 23:19.800
the writing-based system code suite.

23:19.800 --> 23:21.040
So as you can see,

23:21.040 --> 23:26.040
when we should compare with only this part and this part,

23:28.600 --> 23:33.040
which is different, only difference between those two

23:33.040 --> 23:37.080
are the, whether MMM is enabled or not.

23:37.080 --> 23:41.880
And we can see the mostly 10 times faster

23:41.880 --> 23:44.040
for the no MMM part,

23:44.040 --> 23:46.840
which is mostly because of the simplicity

23:46.840 --> 23:49.640
of the no MMM, no MMM calendar.

23:49.640 --> 23:53.160
And the MMM full kernel has a desperate moment,

23:53.160 --> 23:55.840
but they had, they had the generality

23:55.840 --> 23:58.200
for the application support.

23:58.200 --> 24:02.000
And the bottom part is also using the same five configuration,

24:02.000 --> 24:05.960
with the LM-Benz suite and also iPad V.

24:05.960 --> 24:08.480
And the trend for the performance number is almost similar

24:08.480 --> 24:11.240
to what get the PIDs benchmark does.

24:13.160 --> 24:17.320
So I'm sharing some of the discussion in the mailing list.

24:17.320 --> 24:21.640
And the most of the kernel,

24:21.640 --> 24:25.800
the beta-quarly cognites that this extension series

24:25.800 --> 24:28.400
used through to test the no MMM code,

24:28.400 --> 24:29.800
is the K unit.

24:30.760 --> 24:35.600
And somebody also expressed the interest

24:35.600 --> 24:40.840
on the head, the interest on the 20-utiles,

24:40.840 --> 24:44.320
if this is a pristine thing in the future.

24:44.320 --> 24:47.160
And the speed up, as I mentioned in the previous slide,

24:47.160 --> 24:51.120
is coming from the simplicity of the no MMM calendar,

24:51.120 --> 24:55.240
but this is at the cost of the lack of the generality

24:55.240 --> 24:57.960
for the application support, because of the severality

24:57.960 --> 25:02.160
score restriction, as I explained.

25:02.160 --> 25:05.440
And I, so for the next step,

25:05.440 --> 25:07.360
is I will propose this part set

25:07.360 --> 25:12.080
is that Qajan 14 proposal.

25:12.080 --> 25:17.080
And also more wrong attempt on contribution.

25:17.080 --> 25:20.600
We focused the selection, the limitation is very severe,

25:20.600 --> 25:24.360
or severe, critical for our understanding,

25:24.360 --> 25:29.880
but we can also consider the alternate fork implementation.

25:29.880 --> 25:32.560
So the micro fork is essentially proposed

25:32.560 --> 25:35.400
in the academic society.

25:35.400 --> 25:39.000
And this doesn't require the copyright functionality

25:39.000 --> 25:41.800
from the hardware, but they usually

25:41.800 --> 25:46.880
defined mechanism to offer the same functionality

25:46.880 --> 25:49.840
of the fork instead of the before, which

25:49.840 --> 25:53.720
might be used through for this case in the future.

25:53.720 --> 25:55.680
So that's almost it for my talk.

25:55.680 --> 25:59.160
So I introduced our extension, but the no MMM

25:59.160 --> 26:02.800
makes more introduction to the user mode relapse.

26:02.800 --> 26:07.080
And to make testing easier for the no MMM recording

26:07.080 --> 26:08.600
the Linux 3.

26:08.600 --> 26:11.240
And the speed up is optional, and the bonus point

26:11.240 --> 26:16.760
for the implementation, but this is at the cost of the list

26:16.760 --> 26:19.480
in this generality.

26:19.480 --> 26:23.880
And the value of 14 should be very skipped,

26:23.880 --> 26:29.880
very slightly after going back to my home.

26:29.880 --> 26:31.840
So thank you for all this thing.

26:31.840 --> 26:33.880
And I'm happy to take any questions you have.

26:33.880 --> 26:45.160
Thank you for the nice work.

26:45.160 --> 26:52.040
My question is that you use the alpine based

26:52.040 --> 26:56.520
mussel tool chain, with busy box will build root,

26:56.520 --> 26:59.840
where there is an option just to compile.

26:59.840 --> 27:03.160
And this was 64 bit only for x86.

27:03.160 --> 27:05.560
Only for x86.

27:05.560 --> 27:07.600
I think only this file also there

27:07.600 --> 27:09.840
is a 32 bit option.

27:09.840 --> 27:12.760
And a lot of people are trying to boot Linux

27:12.760 --> 27:16.160
on ESP32 or Raspberry Pi P code.

27:16.160 --> 27:19.360
So they also make a lot of use there.

27:19.360 --> 27:26.360
So maybe we can collaborate on this effort to get it in such a way.

27:26.360 --> 27:35.600
So it's a continuation, like podmon containers.

27:35.600 --> 27:40.760
We work on kind of this MMM disabled.

27:40.760 --> 27:42.480
I'm sorry, I didn't get to go across that.

27:42.480 --> 27:46.080
It's continuation, like podmon containers,

27:46.080 --> 27:51.320
working on Linux kernel when MMM is deactivated.

27:51.320 --> 27:55.160
Like this, no MMM, I agree.

27:55.160 --> 27:59.840
I'm not sure if this is ready to run to our extension,

27:59.840 --> 28:02.080
but this is the very, this is very useful

28:02.080 --> 28:03.600
specific implementation.

28:03.600 --> 28:08.360
It doesn't, it can be useful for the darling content

28:08.360 --> 28:11.720
on top of this email, this application.

28:11.720 --> 28:16.720
But I don't know, maybe I will ask you later for more detail.

28:16.720 --> 28:18.720
I don't understand what's going to be the question, I'm sorry.

28:30.320 --> 28:31.080
Thank you.

28:31.080 --> 28:34.240
In your comparison slides, where you

28:34.240 --> 28:39.800
just compared the speed of UML, MMU, UML, no MMU,

28:39.800 --> 28:41.280
and just UML.

28:41.280 --> 28:45.360
So what's the difference between just UML and UML, MMU?

28:45.360 --> 28:46.720
I didn't get that.

28:46.720 --> 28:49.600
I didn't hear the last part of your question.

28:49.600 --> 28:54.160
So what's the difference between normal UML and UML, MMU?

28:54.160 --> 28:55.160
OK.

28:55.160 --> 29:03.400
So the biggest difference is that the MMM,

29:03.400 --> 29:06.760
the relation part of the original UML implementation.

29:06.760 --> 29:10.360
We don't have a page table, so we don't have to emulate

29:10.440 --> 29:12.920
the page for, for example,

29:12.920 --> 29:15.800
and also, it doesn't have to implement the page

29:15.800 --> 29:18.400
in switching page table between the multiple UMLs,

29:18.400 --> 29:19.240
that's the supposed to be.

29:19.240 --> 29:23.360
That will be the very, primarily difference between the UML.

29:23.360 --> 29:24.520
Thank you.

29:24.520 --> 29:25.520
OK, thank you.

29:25.520 --> 29:26.520
Thank you.

29:26.920 --> 29:27.720
Thank you.

29:36.360 --> 29:36.680
Thank you.

29:36.680 --> 29:38.880
Thank you very much.

29:40.880 --> 29:41.880
Bye.

29:41.880 --> 29:42.360
Bye.

29:43.360 --> 29:44.040
Bye.

29:44.040 --> 29:45.080
So...