WEBVTT

00:00.000 --> 00:10.000
You're right, so can people in the back hear me okay?

00:10.000 --> 00:13.000
Yeah, louder, okay.

00:13.000 --> 00:18.000
I'll try to go loud and we'll see how far my voice goes.

00:18.000 --> 00:19.000
So my name is Stephanie Hansen.

00:19.000 --> 00:22.000
I work at Oracle in the G7 team.

00:22.000 --> 00:26.000
I've been doing G7 for the past 12 years.

00:26.000 --> 00:28.000
Mostly focusing on G1.

00:28.000 --> 00:31.000
And lately I've been doing more and more CGC work.

00:31.000 --> 00:34.000
And that's what I will be talking about today.

00:34.000 --> 00:39.000
How we're making CGC as easy to use as possible.

00:39.000 --> 00:43.000
And this is kind of a sibling talk to one

00:43.000 --> 00:46.000
that my colleague Eric Ostlin will be giving a jaw one.

00:46.000 --> 00:48.000
Since we have a bit shorter time here,

00:48.000 --> 00:53.000
I will be focusing on some of the things that we've seen with Linux

00:53.000 --> 00:57.000
when you're around CGC and some configuration problems there.

00:57.000 --> 01:01.000
And yeah, point up if I need to raise my voice.

01:01.000 --> 01:05.000
First of all, short introduction to CGC.

01:05.000 --> 01:10.000
We want CGC to be a really good low latency alternative for Java.

01:10.000 --> 01:14.000
And that means providing pause times below one millisecond.

01:14.000 --> 01:17.000
We also want CGC to be very scalable.

01:17.000 --> 01:19.000
So it should be able to handle terabyte size tips

01:19.000 --> 01:22.000
without what the pause is growing in the larger.

01:22.000 --> 01:26.000
And we also want CGC to be very seduced.

01:26.000 --> 01:31.000
And the user should be required to minimal amount of configuration.

01:31.000 --> 01:35.000
So if we look at the current status of the CGC,

01:35.000 --> 01:37.000
and when it comes to low latency,

01:37.000 --> 01:40.000
we feel like we tick all of the boxes.

01:40.000 --> 01:43.000
And the pauses are most therefore synchronization reasons.

01:43.000 --> 01:46.000
So to make sure that the CGC and the application friends agree

01:46.000 --> 01:49.000
on what they're currently in or remarking objects

01:49.000 --> 01:52.000
or are re-releicating objects or what's going on.

01:52.000 --> 01:55.000
So all the heavyages that work is done concurrently

01:55.000 --> 01:57.000
with the Java application running.

01:57.000 --> 01:59.000
So that's really great.

01:59.000 --> 02:01.000
From a scalability point of view,

02:01.000 --> 02:03.000
we also feel very okay.

02:03.000 --> 02:05.000
And most of the boxes are ticked.

02:05.000 --> 02:07.000
We can support up to 16 terabytes of tips

02:07.000 --> 02:09.000
and the pauses are still short.

02:09.000 --> 02:12.000
And what's really fun is that we recently started

02:12.000 --> 02:16.000
to get some reports that people are using large hits,

02:16.000 --> 02:17.000
with CGC.

02:17.000 --> 02:18.000
They found some issues,

02:18.000 --> 02:21.000
and we're trying to even out the rough edges

02:21.000 --> 02:23.000
around the corners here.

02:23.000 --> 02:25.000
So that's really great to see.

02:25.000 --> 02:28.000
When it comes to the out-to-tuning part,

02:28.000 --> 02:31.000
we do a lot of configuration automatically.

02:31.000 --> 02:34.000
But there's still a few boxes left to tick.

02:34.000 --> 02:37.000
But still the number of threads are sized automatically.

02:37.000 --> 02:40.000
The generation sizes are sized automatically.

02:40.000 --> 02:44.000
We figure out when to promote all these to the old generation automatically.

02:44.000 --> 02:46.000
We basically tell the user,

02:46.000 --> 02:48.000
just set the heat size.

02:48.000 --> 02:51.000
The problem with that is setting an optimal heat size.

02:51.000 --> 02:53.000
It might not be as easy as it sounds,

02:53.000 --> 02:55.000
because you need to take into account

02:55.000 --> 02:59.000
what other things are running on the same machine or in the container.

02:59.000 --> 03:03.000
You need to understand how much memory the JVM itself needs.

03:03.000 --> 03:05.000
The code cache needs memory and other things

03:05.000 --> 03:07.000
in the JVM also needs memory.

03:07.000 --> 03:09.000
So if we could size this automatically,

03:09.000 --> 03:10.000
it would be great.

03:10.000 --> 03:13.000
And this is a product that our guests are in this leading

03:13.000 --> 03:16.000
to add automatic heat-sizing for CGC.

03:16.000 --> 03:19.000
And he will be covering that in much greater detail

03:19.000 --> 03:21.000
in his talk in JVM.

03:21.000 --> 03:23.000
So if you have the opportunity to go there,

03:23.000 --> 03:25.000
do it and watch his talk.

03:25.000 --> 03:27.000
Because it's a really interesting topic.

03:27.000 --> 03:33.000
Yeah, I think this is it for the introduction to CGC.

03:33.000 --> 03:37.000
Now I want to talk a bit about some of the design decisions

03:37.000 --> 03:42.000
that we've done in CGC and how they differ a bit from the traditional uses.

03:42.000 --> 03:45.000
The first question is why different.

03:45.000 --> 03:49.000
And the reason for this is to achieve all those goals

03:49.000 --> 03:50.000
that we stated,

03:50.000 --> 03:52.000
CGC needs to be a concurrent collector.

03:52.000 --> 03:56.000
Because otherwise we won't be able to write this really low latency.

03:56.000 --> 03:59.000
And when you have a concurrent collector,

03:59.000 --> 04:01.000
you get slightly different trade-offs

04:01.000 --> 04:02.000
compared to the traditional uses

04:02.000 --> 04:05.000
where you do most of the JVM's inside the JVM posts.

04:05.000 --> 04:07.000
When you do a lot of work in the posts,

04:07.000 --> 04:10.000
you need to make sure that the post is very effective and short.

04:10.000 --> 04:14.000
Because otherwise it will affect the latency of the application.

04:14.000 --> 04:16.000
When you have a concurrent collector in the process

04:16.000 --> 04:18.000
or way below a millisecond,

04:18.000 --> 04:22.000
like 100 microseconds having a post is not that big of a deal.

04:22.000 --> 04:24.000
But instead you need to focus on other things.

04:24.000 --> 04:27.000
And two of the main focus areas for CGC

04:27.000 --> 04:30.000
is to keep the concurrency overhead low.

04:30.000 --> 04:32.000
And what will basically mean by that

04:32.000 --> 04:34.000
is make sure that the application throughput

04:34.000 --> 04:38.000
isn't affected too much by also doing concurrent G

04:38.000 --> 04:40.000
is a work alongside the Java application.

04:40.000 --> 04:43.000
We also want the heat memory headroom

04:43.000 --> 04:46.000
or overhead to be as low as possible.

04:46.000 --> 04:49.000
So since the application is running

04:49.000 --> 04:51.000
alongside the GCC,

04:51.000 --> 04:53.000
the application will continue allocating memory.

04:53.000 --> 04:56.000
So we need to make sure that the GCC free up memory

04:56.000 --> 04:59.000
before the application allocates it all.

04:59.000 --> 05:02.000
So this is a big part of the concurrent collector too.

05:02.000 --> 05:04.000
To keep the headroom low.

05:04.000 --> 05:07.000
So one of the key design decisions

05:07.000 --> 05:11.000
is to achieve its colored pointers.

05:11.000 --> 05:14.000
And we basically make use of most of the 64 bits

05:14.000 --> 05:17.000
and a 64-bit pointer with colored pointers.

05:17.000 --> 05:20.000
There are 46 bits for addressing.

05:20.000 --> 05:23.000
And we have 12 metadata bits.

05:23.000 --> 05:26.000
And more here are the metadata bits.

05:26.000 --> 05:29.000
They allow us to solve some really complex problems

05:29.000 --> 05:31.000
in a really efficient way.

05:31.000 --> 05:35.000
So for example, it enables us to have very low GCC overhead.

05:35.000 --> 05:37.000
But just a few instructions,

05:37.000 --> 05:40.000
we're able to determine whether it's safe to use a pointer

05:40.000 --> 05:44.000
or not if it needs to be fixed before they use it.

05:44.000 --> 05:48.000
And having that feature, being able to very efficiently look at a pointer

05:48.000 --> 05:51.000
and know, can we use this pointer right away or not.

05:51.000 --> 05:54.000
We're able to do very eager memory recognition.

05:54.000 --> 05:56.000
And the way we do this is,

05:56.000 --> 06:01.000
since we can look at a pointer and know if it needs to be fixed or not,

06:01.000 --> 06:04.000
we know that we will never look in a region

06:04.000 --> 06:06.000
where an object is not located anymore.

06:06.000 --> 06:09.000
So if we have a located all live objects in a memory region,

06:09.000 --> 06:12.000
we can hand that back to the application as soon as the

06:12.000 --> 06:13.000
location is done.

06:13.000 --> 06:16.000
We don't need to remap all the pointers point the

06:16.000 --> 06:17.000
into this region.

06:17.000 --> 06:20.000
Because we know that no state pointers will ever be

06:20.000 --> 06:21.000
accessed into this region.

06:21.000 --> 06:24.000
So we can reuse the memory very quickly.

06:24.000 --> 06:28.000
And another thing that this makes us make us possible

06:28.000 --> 06:31.000
to do since we have 46 bits for addressing,

06:31.000 --> 06:33.000
we can have a discontinuous heap.

06:33.000 --> 06:36.000
So basically, we reserve additional virtual memory

06:36.000 --> 06:38.000
address space for the heap in CGC.

06:38.000 --> 06:41.000
A traditional GGC basically reserve the same amount of

06:41.000 --> 06:44.000
virtual address space as we have the heap size.

06:44.000 --> 06:48.000
But in CGC, we reserve up to 16 times as much

06:48.000 --> 06:51.000
virtual address space compared to the heap size.

06:51.000 --> 06:54.000
And the main reason for this is to avoid fragmentation.

06:54.000 --> 06:58.000
So if we do this, we'll almost always be able to find room for

06:58.000 --> 07:00.000
large allocation.

07:00.000 --> 07:03.000
And you might use G1 in the past or you might be using

07:03.000 --> 07:05.000
G1 and have some problems with you on this object.

07:05.000 --> 07:07.000
And the handling of you on this object in

07:07.000 --> 07:10.000
G1 has improved a lot over the last few years.

07:10.000 --> 07:13.000
Still they introduce some issues.

07:13.000 --> 07:16.000
And by doing this, having the additional

07:16.000 --> 07:19.000
virtual address space and always being able to find room,

07:19.000 --> 07:22.000
we can get away from most of those problems.

07:22.000 --> 07:24.000
So that's pretty neat.

07:24.000 --> 07:27.000
And other thing that differs between CGC and

07:27.000 --> 07:32.000
many other businesses is backed by shared memory.

07:32.000 --> 07:36.000
And the reason for this is that in non-generational

07:36.000 --> 07:40.000
CGC, we needed to do this because we mapped the heap

07:40.000 --> 07:41.000
at multiple addresses.

07:41.000 --> 07:45.000
So the way that the caller pointers worked in non-generational

07:45.000 --> 07:48.000
CGC was that we had multiple views over the heap

07:48.000 --> 07:52.000
and the metadata bits told us which view was the current one.

07:52.000 --> 07:55.000
With generational CGC, we instead have a feature called

07:55.000 --> 07:56.000
LLS Roots.

07:56.000 --> 08:00.000
So the efficient code is able to save away the metadata bits

08:00.000 --> 08:03.000
and we only have a single view of the heap and a single address

08:03.000 --> 08:04.000
for the heap.

08:04.000 --> 08:07.000
So that's nice because it gives us additional

08:07.000 --> 08:10.000
and we can support even larger hits with generations.

08:10.000 --> 08:12.000
So that's pretty nice.

08:12.000 --> 08:15.000
And still, we make use of shared memory even though

08:15.000 --> 08:18.000
we don't need it for generational CGC.

08:18.000 --> 08:20.000
Because we can do some things that we can do in

08:21.000 --> 08:22.000
on this memory.

08:22.000 --> 08:25.000
For example, it allows us to do lazy and mapping.

08:25.000 --> 08:28.000
So for example, if you need to fit the logic

08:28.000 --> 08:30.000
into the virtual address space, you can

08:30.000 --> 08:34.000
map memory to a new location where you have room for this logic.

08:34.000 --> 08:37.000
But you don't have to un-map the location of the old memory.

08:37.000 --> 08:39.000
You can do that lazily in the thread that is not

08:39.000 --> 08:41.000
performance critical.

08:41.000 --> 08:45.000
So there are still some pros of using shared memory.

08:45.000 --> 08:49.000
But we do experiments with moving to on this memory

08:49.000 --> 08:52.000
because being the old one out and not using

08:52.000 --> 08:55.000
the same techniques as others can come with problems.

08:55.000 --> 08:59.000
And that's what I'm going to talk about in this next

08:59.000 --> 09:02.000
section that these new techniques that we're using.

09:02.000 --> 09:06.000
On Linux, they give us some configuration problems

09:06.000 --> 09:08.000
or issues.

09:08.000 --> 09:11.000
And we want to try to avoid those because we want

09:11.000 --> 09:13.000
to minimize their amount of configuration.

09:13.000 --> 09:16.000
But I'm going to tell you a bit about two of the things

09:16.000 --> 09:18.000
that we're seeing on Linux.

09:18.000 --> 09:21.000
The first one being that with CDC,

09:21.000 --> 09:24.000
sometimes get very strange need of old memory.

09:24.000 --> 09:29.000
I say strange because it's still plenty of memory left on the machine.

09:29.000 --> 09:32.000
But still like M map or M protect,

09:32.000 --> 09:34.000
or any of the other low-level calls,

09:34.000 --> 09:37.000
making changes to the virtual memory mapping in Linux

09:37.000 --> 09:38.000
return you know map.

09:38.000 --> 09:40.000
So there is no memory left.

09:40.000 --> 09:43.000
And the reason for this is that we hit a kernel limit

09:43.000 --> 09:45.000
called VM max map count.

09:45.000 --> 09:48.000
And this limit tells you how many mappings of process

09:48.000 --> 09:50.000
can have at most.

09:50.000 --> 09:54.000
And when you have a very large heap,

09:54.000 --> 09:57.000
CDC, since we have this discontinuously,

09:57.000 --> 09:59.000
might need a lot of mappings.

09:59.000 --> 10:02.000
Because depending on the allocation pattern on the application,

10:02.000 --> 10:06.000
we might do more mappings than a traditional disease.

10:06.000 --> 10:10.000
So on startup, CDC looks at this value,

10:10.000 --> 10:13.000
compared to the heap size that is set,

10:13.000 --> 10:17.000
and sends out a warning if the value is too low.

10:17.000 --> 10:19.000
And then also gives us a suggestion on how

10:19.000 --> 10:22.000
to configure this value properly for your given heap size.

10:22.000 --> 10:25.000
In many cases, you won't run into hitting this limit

10:25.000 --> 10:27.000
because your application doesn't have allocation patterns

10:27.000 --> 10:29.000
that triggers this.

10:29.000 --> 10:32.000
But sometimes this warning actually tells you what you need to do

10:32.000 --> 10:35.000
to really be able to use CDC in an efficient way.

10:35.000 --> 10:38.000
The problem is that depending on how you're deploying your system,

10:38.000 --> 10:41.000
seeing this warning might be problematic and you might just

10:41.000 --> 10:45.000
see it out of memory and don't really understand why.

10:45.000 --> 10:47.000
So what can we do about this?

10:47.000 --> 10:49.000
Well, to get to the bottom of that,

10:49.000 --> 10:53.000
we need to first understand this limit a bit more.

10:53.000 --> 10:59.000
And the math count limit seems to be mostly there for historical reasons.

10:59.000 --> 11:02.000
Back in the day, the elephant had restrictions,

11:02.000 --> 11:05.000
and this led to core files only being able to handle

11:05.000 --> 11:08.000
64K case of mapping.

11:08.000 --> 11:12.000
So the default value was set to 64K.

11:12.000 --> 11:15.000
Since then, the elephant has been extended,

11:15.000 --> 11:19.000
and the core files have been improved to be able to handle this extension.

11:19.000 --> 11:24.000
So this limitation is no longer a reason for this limit being low.

11:24.000 --> 11:28.000
It still is, and it's not only so you see the running

11:28.000 --> 11:29.000
to problems with this.

11:29.000 --> 11:31.000
There are numerous cases online,

11:31.000 --> 11:34.000
if you search for outer memory problems,

11:34.000 --> 11:36.000
where people have spent a lot of time

11:36.000 --> 11:39.000
to try to understand why there are certain application or game run

11:39.000 --> 11:41.000
into problems with outer memory,

11:41.000 --> 11:44.000
while there is still a lot of memory left on the system.

11:44.000 --> 11:48.000
And there is games in memory databases

11:48.000 --> 11:51.000
that actually state clearly in their documentation.

11:51.000 --> 11:53.000
You need to reconfigure this value,

11:53.000 --> 11:56.000
otherwise our in memory database won't work properly.

11:56.000 --> 12:00.000
So our plan going forward is to try to influence

12:00.000 --> 12:02.000
a change to this default value.

12:02.000 --> 12:04.000
And we'll see how that goes.

12:04.000 --> 12:07.000
We're not the first ones that have thought this question

12:07.000 --> 12:09.000
and seen the problems with this.

12:09.000 --> 12:12.000
So there are multiple emails on the Linux mailing list

12:12.000 --> 12:16.000
suggesting either to remove this limit or to increase it.

12:16.000 --> 12:20.000
Still, most of those attempts have been shut down

12:20.000 --> 12:21.000
or all of them.

12:21.000 --> 12:25.000
But we'll try to work probably with internal Oracle Linux teams

12:25.000 --> 12:30.000
to see if we can argue for this limit being raised.

12:30.000 --> 12:33.000
Because we want y'all to be able to run properly.

12:33.000 --> 12:36.000
Without configuration on all distributions.

12:36.000 --> 12:39.000
There are actually a few distributions that already

12:39.000 --> 12:40.000
up this limit by default.

12:40.000 --> 12:42.000
I think you've been to for example,

12:42.000 --> 12:44.000
ships with a default value one million.

12:44.000 --> 12:47.000
But it would be really great if the default from Linux

12:47.000 --> 12:50.000
would be larger.

12:50.000 --> 12:54.000
Yeah, kind of, but you can set it at runtime as well.

12:54.000 --> 12:56.000
So it's easy to configure.

12:56.000 --> 12:59.000
And it's really no drawback in configuring this to a larger value.

12:59.000 --> 13:01.000
You will use a bit more kernel memory

13:02.000 --> 13:04.000
because they are kernel data structures.

13:04.000 --> 13:08.000
And this is kind of one of the reasons

13:08.000 --> 13:11.000
or arguments made for not changing this that you could

13:11.000 --> 13:14.000
maybe force out of memory using kernel memory

13:14.000 --> 13:16.000
if you raised this value too high.

13:16.000 --> 13:20.000
Yeah, we will have to argue around those things

13:20.000 --> 13:22.000
if we want to change this.

13:22.000 --> 13:25.000
Another thing that requires configuration on Linux

13:25.000 --> 13:27.000
and it's something that's very important.

13:27.000 --> 13:30.000
If you want great performance with y'all, it's huge pages.

13:31.000 --> 13:35.000
In the path, we've encouraged people to use explicit use pages

13:35.000 --> 13:40.000
or a huge TLB use pages because they are very deterministic

13:40.000 --> 13:44.000
and once you have reserved them, they will be available for use.

13:44.000 --> 13:47.000
The problem is that you have to reserve them up front

13:47.000 --> 13:50.000
and to be able to know how many to reserve you need to decide

13:50.000 --> 13:51.000
upon a heap size.

13:51.000 --> 13:56.000
And as I mentioned, we want to make the heap size automatically

13:57.000 --> 14:00.000
than this is not the very good effect.

14:00.000 --> 14:03.000
So what kind of alternative do we have?

14:03.000 --> 14:06.000
Well, we have the transparent huge pages.

14:06.000 --> 14:12.000
They were introduced a long time ago, more than 10 years ago at least.

14:12.000 --> 14:17.000
And at the time of introduction, they came with some performance drawbacks.

14:17.000 --> 14:20.000
We saw latency issues when using transparent huge pages

14:20.000 --> 14:23.000
due to the kernel having to defragment memory

14:24.000 --> 14:27.000
to be able to satisfy transparent huge pages requests.

14:27.000 --> 14:32.000
Later, or recently, we don't see as many problems with transparent huge pages

14:32.000 --> 14:36.000
so we're getting more and more comfortable in encouraging uses

14:36.000 --> 14:38.000
to use transparent huge pages.

14:38.000 --> 14:39.000
So this is great.

14:39.000 --> 14:43.000
Still transparent huge pages that require some configuration

14:43.000 --> 14:47.000
and especially for shared memory, it often requires configuration

14:47.000 --> 14:49.000
to be able to be used.

14:50.000 --> 14:53.000
So let's look a bit closer at what kind of configuration

14:53.000 --> 14:56.000
you have to do for transparent huge pages.

14:56.000 --> 14:59.000
And the THP or transparent huge page mode,

14:59.000 --> 15:01.000
basically how three different values,

15:01.000 --> 15:03.000
it can be configured as always,

15:03.000 --> 15:06.000
meaning that as soon as you have a mapping

15:06.000 --> 15:09.000
that has the correct alignment and the correct size,

15:09.000 --> 15:12.000
the mapping will be backed by transparent huge pages.

15:12.000 --> 15:15.000
The Linux system will try to back the mapping

15:15.000 --> 15:16.000
with transparent huge pages.

15:17.000 --> 15:19.000
Or it can be configured as advice.

15:19.000 --> 15:22.000
In that case, US and application developer or JVM developer

15:22.000 --> 15:24.000
need to specify that,

15:24.000 --> 15:27.000
this mapping with a correct alignment and the correct size

15:27.000 --> 15:30.000
I want this to be backed by transparent huge pages

15:30.000 --> 15:32.000
by using M and vice.

15:32.000 --> 15:35.000
Or it can be configured as never,

15:35.000 --> 15:37.000
and kind of explains itself,

15:37.000 --> 15:41.000
you will never use transparent huge pages to back any mappings.

15:41.000 --> 15:45.000
And all of this memory and shared memory are configured separately

15:46.000 --> 15:49.000
and this is a bit problematic to suggested,

15:49.000 --> 15:51.000
mainly because the defaults are different.

15:51.000 --> 15:54.000
So on many distributions, the default for a shared,

15:54.000 --> 15:56.000
for anonymous memory is always,

15:56.000 --> 15:59.000
while the default for shared memory is never.

15:59.000 --> 16:01.000
So you should really check your configuration

16:01.000 --> 16:04.000
and you do this by looking at those two paths,

16:04.000 --> 16:08.000
shared memory, of course, being the second one.

16:08.000 --> 16:12.000
The problem here is that it gives unfair

16:12.000 --> 16:14.000
out of the box comparisons.

16:14.000 --> 16:19.000
So for example, if you compare G1 to CGC

16:19.000 --> 16:22.000
on a default configuration existing,

16:22.000 --> 16:26.000
G1's here will be backed by transparent huge pages,

16:26.000 --> 16:29.000
but the CGC will not be backed by transparent huge pages.

16:29.000 --> 16:33.000
And from a performance point of view, this is very unfair.

16:33.000 --> 16:35.000
And we've seen in the mirror's cases,

16:35.000 --> 16:38.000
both from the outside internal groups,

16:38.000 --> 16:41.000
where we get the feedback while CGC looks due age from the late

16:41.000 --> 16:42.000
point of view.

16:42.000 --> 16:44.000
But when it comes to the throughput performance,

16:44.000 --> 16:47.000
would you see like a 10 to 15% performance

16:47.000 --> 16:49.000
or throughput regulation?

16:49.000 --> 16:52.000
And most of the time, this is due to the fact that

16:52.000 --> 16:54.000
they compare again something that may use

16:54.000 --> 16:56.000
of transparent huge pages,

16:56.000 --> 16:59.000
and CGC don't in the default configuration.

16:59.000 --> 17:04.000
So once they're able to configure shared memory properly,

17:04.000 --> 17:07.000
the performance regulation goes away.

17:07.000 --> 17:11.000
The problem with this is that it forces you to do configuration,

17:11.000 --> 17:12.000
and we want to avoid this.

17:12.000 --> 17:15.000
And for some people doing this kind of configuration

17:15.000 --> 17:18.000
is not possible because we run in a container or a system,

17:18.000 --> 17:22.000
we don't have access to update the OS configuration.

17:22.000 --> 17:24.000
So what can we do then?

17:24.000 --> 17:27.000
Because yeah, we could move to anonymous memory.

17:27.000 --> 17:30.000
Still, that requires that the configuration is correct

17:30.000 --> 17:31.000
for anonymous memory.

17:31.000 --> 17:34.000
But recently, we actually found this new flag

17:34.000 --> 17:38.000
to a device called Maddy Collapse, which looks very promising.

17:38.000 --> 17:41.000
The drawback is that's only available in the 6.1,

17:41.000 --> 17:43.000
so it's a fairly new thing.

17:43.000 --> 17:46.000
But it might be something for the future.

17:46.000 --> 17:49.000
With this flag, you get much better control

17:49.000 --> 17:52.000
on which mappings will be backed by transparent huge pages,

17:52.000 --> 17:55.000
because when you say Collapse, my mapping with them,

17:55.000 --> 17:58.000
and device, that mapping will be backed by transparent huge pages.

17:58.000 --> 18:02.000
This can of course come with a performance penalty unless

18:02.000 --> 18:04.000
if there are no transparent huge pages available,

18:04.000 --> 18:06.000
then the underlying system needs to do

18:06.000 --> 18:08.000
some different implementation work.

18:08.000 --> 18:11.000
So you need to use this with care.

18:11.000 --> 18:15.000
But the good thing is that it doesn't depend on configuration.

18:15.000 --> 18:18.000
Even though the configuration for shared memories

18:18.000 --> 18:22.000
never using this flag, we're able to get transparent huge pages

18:22.000 --> 18:23.000
for that memory.

18:23.000 --> 18:27.000
So this might be a way forward to avoid configuration.

18:27.000 --> 18:30.000
Again, and making it even easier to use,

18:31.000 --> 18:34.000
and of course, other things that use German memory.

18:34.000 --> 18:38.000
And this was my last main slide.

18:38.000 --> 18:41.000
A few key takeaways from this presentation.

18:41.000 --> 18:43.000
Don't remember the problems.

18:43.000 --> 18:45.000
We're going to fix those.

18:45.000 --> 18:48.000
Instead, remember, or know that,

18:48.000 --> 18:51.000
you see, basically, has no process.

18:51.000 --> 18:53.000
It can handle terabyte size tips,

18:53.000 --> 18:56.000
and it's very, very easy to use.

18:56.000 --> 18:57.000
Thanks.

18:58.000 --> 18:59.000
Thank you.

19:07.000 --> 19:09.000
I spoke too fast, so we have time for questions.

19:12.000 --> 19:13.000
Any questions?

19:13.000 --> 19:15.000
Everything, please, crystal clear?

19:21.000 --> 19:23.000
Looks like it.

19:23.000 --> 19:24.000
Oh, question.

19:28.000 --> 19:29.000
Can I ask you a question?

19:33.000 --> 19:36.000
The collapse flag, it's a flag term advice.

19:36.000 --> 19:38.000
So you can say, like, for this mapping,

19:38.000 --> 19:42.000
I want to make sure that this memory is backed by transparent huge pages.

19:42.000 --> 19:44.000
Yeah.

19:44.000 --> 19:45.000
Yeah.

19:45.000 --> 19:46.000
Okay.

19:46.000 --> 19:47.000
Yeah.

19:47.000 --> 19:49.000
So we should be able to use this.

19:49.000 --> 19:50.000
Oh, yeah.

19:50.000 --> 19:53.000
So the question is about m and vice collapse.

19:53.000 --> 19:56.000
If it's synchronous and from what I understand it is,

19:56.000 --> 19:59.000
and that's why it can come with some performance drawbacks.

19:59.000 --> 20:02.000
So you need to use this with care,

20:02.000 --> 20:04.000
make sure kind of have a priming thread

20:04.000 --> 20:07.000
that makes sure that you don't do this in the application threads,

20:07.000 --> 20:09.000
because that could be expensive.

20:15.000 --> 20:17.000
I mean, you probably wouldn't.

20:17.000 --> 20:21.000
You probably wouldn't do it upfront on the whole thing.

20:21.000 --> 20:23.000
The plan would be, for example,

20:23.000 --> 20:25.000
if you have automatic heat sizing,

20:25.000 --> 20:28.000
you would start with a very small heat.

20:28.000 --> 20:29.000
And then you would grow the heat,

20:29.000 --> 20:32.000
and you would do that in a thread that's not performed as critical.

20:32.000 --> 20:34.000
And you would do this having advice in that thread,

20:34.000 --> 20:37.000
making sure that we'll always have transparent huge pages.

20:37.000 --> 20:40.000
Remember we left, but you don't have to take the heat

20:40.000 --> 20:42.000
in your application thread.

20:42.000 --> 20:44.000
So that's kind of the idea.

20:44.000 --> 20:46.000
Yeah.

20:46.000 --> 20:47.000
Go to all along.

20:51.000 --> 20:52.000
No more questions, I guess.

20:55.000 --> 20:56.000
Thank you.