Re: [RFC v1 2/2] mm: SLUB Freelist randomization

[Joonsoo Kim]

On Fri, May 20, 2016 at 09:24:35AM -0700, Thomas Garnier wrote:
> On Thu, May 19, 2016 at 7:15 PM, Joonsoo Kim  wrote:
> > 2016-05-20 5:20 GMT+09:00 Thomas Garnier :
> >> I ran the test given by Joonsoo and it gave me these minimum cycles
> >> per size across 20 usage:
> >
> > I can't understand what you did here. Maybe, it's due to my poor Engling.
> > Please explain more. You did single thread test? Why minimum cycles
> > rather than average?
> >
> 
> I used your version of slab_test and ran it 20 times for each
> versions. I compared
> the minimum number of cycles as an optimal case for comparison. As you said
> slab_test results can be unreliable. Comparing the average across multiple 
> runs
> always gave odd results.

Hmm... With my version, slab_test results seems to be reliable for me. You
can use average result in this case. Anyway, your minimum result looks
odd even if my version is used. Large sized test would go slowpath
more frequently so it should be worse.

> 
> >> size,before,after
> >> 8,63.00,64.50 (102.38%)
> >> 16,64.50,65.00 (100.78%)
> >> 32,65.00,65.00 (100.00%)
> >> 64,66.00,65.00 (98.48%)
> >> 128,66.00,65.00 (98.48%)
> >> 256,64.00,64.00 (100.00%)
> >> 512,65.00,66.00 (101.54%)
> >> 1024,68.00,64.00 (94.12%)
> >> 2048,66.00,65.00 (98.48%)
> >> 4096,66.00,66.00 (100.00%)
> >
> > It looks like performance of all size classes are the same?
> >
> >> I assume the difference is bigger if you don't have RDRAND support.
> >
> > What does RDRAND means? Kconfig? How can I check if I have RDRAND?
> >
> 
> Sorry, I was referring to the usage of get_random_bytes_arch which
> will be faster
> if the test machine support specific instructions (like RDRAND).

Thanks! I checked that my test bed (QEMU) doesn't support rdrand.
(/proc/cpuinfo)

> >> Christoph, Joonsoo: Do you think it would be valuable to add a CONFIG
> >> to disable additional randomization per new page? It will remove
> >> additional entropy but increase performance for machines without arch
> >> specific randomization instructions.
> >
> > I don't think that it deserve another CONFIG. If performance is a matter,
> > I think that removing additional entropy is better until it is proved that
> > entropy is a problem.
> >
> 
> I will do more testing before the next RFC to decide the best approach.

Okay.

Thanks.

Re: [RFC v1 2/2] mm: SLUB Freelist randomization

[Joonsoo Kim]

On Fri, May 20, 2016 at 09:24:35AM -0700, Thomas Garnier wrote:
> On Thu, May 19, 2016 at 7:15 PM, Joonsoo Kim  wrote:
> > 2016-05-20 5:20 GMT+09:00 Thomas Garnier :
> >> I ran the test given by Joonsoo and it gave me these minimum cycles
> >> per size across 20 usage:
> >
> > I can't understand what you did here. Maybe, it's due to my poor Engling.
> > Please explain more. You did single thread test? Why minimum cycles
> > rather than average?
> >
> 
> I used your version of slab_test and ran it 20 times for each
> versions. I compared
> the minimum number of cycles as an optimal case for comparison. As you said
> slab_test results can be unreliable. Comparing the average across multiple 
> runs
> always gave odd results.

Hmm... With my version, slab_test results seems to be reliable for me. You
can use average result in this case. Anyway, your minimum result looks
odd even if my version is used. Large sized test would go slowpath
more frequently so it should be worse.

> 
> >> size,before,after
> >> 8,63.00,64.50 (102.38%)
> >> 16,64.50,65.00 (100.78%)
> >> 32,65.00,65.00 (100.00%)
> >> 64,66.00,65.00 (98.48%)
> >> 128,66.00,65.00 (98.48%)
> >> 256,64.00,64.00 (100.00%)
> >> 512,65.00,66.00 (101.54%)
> >> 1024,68.00,64.00 (94.12%)
> >> 2048,66.00,65.00 (98.48%)
> >> 4096,66.00,66.00 (100.00%)
> >
> > It looks like performance of all size classes are the same?
> >
> >> I assume the difference is bigger if you don't have RDRAND support.
> >
> > What does RDRAND means? Kconfig? How can I check if I have RDRAND?
> >
> 
> Sorry, I was referring to the usage of get_random_bytes_arch which
> will be faster
> if the test machine support specific instructions (like RDRAND).

Thanks! I checked that my test bed (QEMU) doesn't support rdrand.
(/proc/cpuinfo)

> >> Christoph, Joonsoo: Do you think it would be valuable to add a CONFIG
> >> to disable additional randomization per new page? It will remove
> >> additional entropy but increase performance for machines without arch
> >> specific randomization instructions.
> >
> > I don't think that it deserve another CONFIG. If performance is a matter,
> > I think that removing additional entropy is better until it is proved that
> > entropy is a problem.
> >
> 
> I will do more testing before the next RFC to decide the best approach.

Okay.

Thanks.

Re: [RFC v1 2/2] mm: SLUB Freelist randomization

[Thomas Garnier]

On Thu, May 19, 2016 at 7:15 PM, Joonsoo Kim  wrote:
> 2016-05-20 5:20 GMT+09:00 Thomas Garnier :
>> I ran the test given by Joonsoo and it gave me these minimum cycles
>> per size across 20 usage:
>
> I can't understand what you did here. Maybe, it's due to my poor Engling.
> Please explain more. You did single thread test? Why minimum cycles
> rather than average?
>

I used your version of slab_test and ran it 20 times for each
versions. I compared
the minimum number of cycles as an optimal case for comparison. As you said
slab_test results can be unreliable. Comparing the average across multiple runs
always gave odd results.

>> size,before,after
>> 8,63.00,64.50 (102.38%)
>> 16,64.50,65.00 (100.78%)
>> 32,65.00,65.00 (100.00%)
>> 64,66.00,65.00 (98.48%)
>> 128,66.00,65.00 (98.48%)
>> 256,64.00,64.00 (100.00%)
>> 512,65.00,66.00 (101.54%)
>> 1024,68.00,64.00 (94.12%)
>> 2048,66.00,65.00 (98.48%)
>> 4096,66.00,66.00 (100.00%)
>
> It looks like performance of all size classes are the same?
>
>> I assume the difference is bigger if you don't have RDRAND support.
>
> What does RDRAND means? Kconfig? How can I check if I have RDRAND?
>

Sorry, I was referring to the usage of get_random_bytes_arch which
will be faster
if the test machine support specific instructions (like RDRAND).

>> Christoph, Joonsoo: Do you think it would be valuable to add a CONFIG
>> to disable additional randomization per new page? It will remove
>> additional entropy but increase performance for machines without arch
>> specific randomization instructions.
>
> I don't think that it deserve another CONFIG. If performance is a matter,
> I think that removing additional entropy is better until it is proved that
> entropy is a problem.
>

I will do more testing before the next RFC to decide the best approach.

> Thanks.

Thanks for the comments,
Thomas

Re: [RFC v1 2/2] mm: SLUB Freelist randomization

[Thomas Garnier]

On Thu, May 19, 2016 at 7:15 PM, Joonsoo Kim  wrote:
> 2016-05-20 5:20 GMT+09:00 Thomas Garnier :
>> I ran the test given by Joonsoo and it gave me these minimum cycles
>> per size across 20 usage:
>
> I can't understand what you did here. Maybe, it's due to my poor Engling.
> Please explain more. You did single thread test? Why minimum cycles
> rather than average?
>

I used your version of slab_test and ran it 20 times for each
versions. I compared
the minimum number of cycles as an optimal case for comparison. As you said
slab_test results can be unreliable. Comparing the average across multiple runs
always gave odd results.

>> size,before,after
>> 8,63.00,64.50 (102.38%)
>> 16,64.50,65.00 (100.78%)
>> 32,65.00,65.00 (100.00%)
>> 64,66.00,65.00 (98.48%)
>> 128,66.00,65.00 (98.48%)
>> 256,64.00,64.00 (100.00%)
>> 512,65.00,66.00 (101.54%)
>> 1024,68.00,64.00 (94.12%)
>> 2048,66.00,65.00 (98.48%)
>> 4096,66.00,66.00 (100.00%)
>
> It looks like performance of all size classes are the same?
>
>> I assume the difference is bigger if you don't have RDRAND support.
>
> What does RDRAND means? Kconfig? How can I check if I have RDRAND?
>

Sorry, I was referring to the usage of get_random_bytes_arch which
will be faster
if the test machine support specific instructions (like RDRAND).

>> Christoph, Joonsoo: Do you think it would be valuable to add a CONFIG
>> to disable additional randomization per new page? It will remove
>> additional entropy but increase performance for machines without arch
>> specific randomization instructions.
>
> I don't think that it deserve another CONFIG. If performance is a matter,
> I think that removing additional entropy is better until it is proved that
> entropy is a problem.
>

I will do more testing before the next RFC to decide the best approach.

> Thanks.

Thanks for the comments,
Thomas

Re: [RFC v1 2/2] mm: SLUB Freelist randomization

[Joonsoo Kim]

2016-05-20 5:20 GMT+09:00 Thomas Garnier :
> I ran the test given by Joonsoo and it gave me these minimum cycles
> per size across 20 usage:

I can't understand what you did here. Maybe, it's due to my poor Engling.
Please explain more. You did single thread test? Why minimum cycles
rather than average?

> size,before,after
> 8,63.00,64.50 (102.38%)
> 16,64.50,65.00 (100.78%)
> 32,65.00,65.00 (100.00%)
> 64,66.00,65.00 (98.48%)
> 128,66.00,65.00 (98.48%)
> 256,64.00,64.00 (100.00%)
> 512,65.00,66.00 (101.54%)
> 1024,68.00,64.00 (94.12%)
> 2048,66.00,65.00 (98.48%)
> 4096,66.00,66.00 (100.00%)

It looks like performance of all size classes are the same?

> I assume the difference is bigger if you don't have RDRAND support.

What does RDRAND means? Kconfig? How can I check if I have RDRAND?

> Christoph, Joonsoo: Do you think it would be valuable to add a CONFIG
> to disable additional randomization per new page? It will remove
> additional entropy but increase performance for machines without arch
> specific randomization instructions.

I don't think that it deserve another CONFIG. If performance is a matter,
I think that removing additional entropy is better until it is proved that
entropy is a problem.

Thanks.

Re: [RFC v1 2/2] mm: SLUB Freelist randomization

[Joonsoo Kim]

2016-05-20 5:20 GMT+09:00 Thomas Garnier :
> I ran the test given by Joonsoo and it gave me these minimum cycles
> per size across 20 usage:

I can't understand what you did here. Maybe, it's due to my poor Engling.
Please explain more. You did single thread test? Why minimum cycles
rather than average?

> size,before,after
> 8,63.00,64.50 (102.38%)
> 16,64.50,65.00 (100.78%)
> 32,65.00,65.00 (100.00%)
> 64,66.00,65.00 (98.48%)
> 128,66.00,65.00 (98.48%)
> 256,64.00,64.00 (100.00%)
> 512,65.00,66.00 (101.54%)
> 1024,68.00,64.00 (94.12%)
> 2048,66.00,65.00 (98.48%)
> 4096,66.00,66.00 (100.00%)

It looks like performance of all size classes are the same?

> I assume the difference is bigger if you don't have RDRAND support.

What does RDRAND means? Kconfig? How can I check if I have RDRAND?

> Christoph, Joonsoo: Do you think it would be valuable to add a CONFIG
> to disable additional randomization per new page? It will remove
> additional entropy but increase performance for machines without arch
> specific randomization instructions.

I don't think that it deserve another CONFIG. If performance is a matter,
I think that removing additional entropy is better until it is proved that
entropy is a problem.

Thanks.

Re: [RFC v1 2/2] mm: SLUB Freelist randomization

[Thomas Garnier]

I ran the test given by Joonsoo and it gave me these minimum cycles
per size across 20 usage:

size,before,after
8,63.00,64.50 (102.38%)
16,64.50,65.00 (100.78%)
32,65.00,65.00 (100.00%)
64,66.00,65.00 (98.48%)
128,66.00,65.00 (98.48%)
256,64.00,64.00 (100.00%)
512,65.00,66.00 (101.54%)
1024,68.00,64.00 (94.12%)
2048,66.00,65.00 (98.48%)
4096,66.00,66.00 (100.00%)

I assume the difference is bigger if you don't have RDRAND support.

Christoph, Joonsoo: Do you think it would be valuable to add a CONFIG
to disable additional randomization per new page? It will remove
additional entropy but increase performance for machines without arch
specific randomization instructions.

Thanks,
Thomas


On Wed, May 18, 2016 at 7:07 PM, Joonsoo Kim  wrote:
> On Wed, May 18, 2016 at 12:12:13PM -0700, Thomas Garnier wrote:
>> I thought the mix of slab_test & kernbench would show a diverse
>> picture on perf data. Is there another test that you think would be
>> useful?
>
> Single thread testing on slab_test would be meaningful because it also
> touch the slowpath. Problem is just unstable result of slab_test.
>
> You can get more stable result of slab_test if you repeat same test
> sometimes and get average result.
>
> Please use following slab_test. It will do each operations 10
> times and repeat it 50 times.
>
> https://github.com/JoonsooKim/linux/blob/slab_test_robust-next-20160509/mm/slab_test.c
>
> I did a quick test for this patchset and get following result.
>
> - Before (With patch and randomization is disabled by config)
>
> Single thread testing
> =
> 1. Kmalloc: Repeatedly allocate then free test
> 10 times kmalloc(8) -> 42 cycles kfree -> 67 cycles
> 10 times kmalloc(16) -> 43 cycles kfree -> 68 cycles
> 10 times kmalloc(32) -> 47 cycles kfree -> 72 cycles
> 10 times kmalloc(64) -> 54 cycles kfree -> 78 cycles
> 10 times kmalloc(128) -> 75 cycles kfree -> 87 cycles
> 10 times kmalloc(256) -> 84 cycles kfree -> 111 cycles
> 10 times kmalloc(512) -> 82 cycles kfree -> 112 cycles
> 10 times kmalloc(1024) -> 86 cycles kfree -> 113 cycles
> 10 times kmalloc(2048) -> 113 cycles kfree -> 127 cycles
> 10 times kmalloc(4096) -> 151 cycles kfree -> 154 cycles
>
> - After (With patch and randomization is enabled by config)
>
> Single thread testing
> =
> 1. Kmalloc: Repeatedly allocate then free test
> 10 times kmalloc(8) -> 51 cycles kfree -> 68 cycles
> 10 times kmalloc(16) -> 57 cycles kfree -> 70 cycles
> 10 times kmalloc(32) -> 70 cycles kfree -> 75 cycles
> 10 times kmalloc(64) -> 95 cycles kfree -> 84 cycles
> 10 times kmalloc(128) -> 142 cycles kfree -> 97 cycles
> 10 times kmalloc(256) -> 150 cycles kfree -> 107 cycles
> 10 times kmalloc(512) -> 151 cycles kfree -> 107 cycles
> 10 times kmalloc(1024) -> 154 cycles kfree -> 110 cycles
> 10 times kmalloc(2048) -> 230 cycles kfree -> 124 cycles
> 10 times kmalloc(4096) -> 423 cycles kfree -> 165 cycles
>
> It seems that performance decreases a lot but I don't care about it
> because it is a security feature and I don't have a better idea.
>
> Thanks.

Re: [RFC v1 2/2] mm: SLUB Freelist randomization

[Thomas Garnier]

I ran the test given by Joonsoo and it gave me these minimum cycles
per size across 20 usage:

size,before,after
8,63.00,64.50 (102.38%)
16,64.50,65.00 (100.78%)
32,65.00,65.00 (100.00%)
64,66.00,65.00 (98.48%)
128,66.00,65.00 (98.48%)
256,64.00,64.00 (100.00%)
512,65.00,66.00 (101.54%)
1024,68.00,64.00 (94.12%)
2048,66.00,65.00 (98.48%)
4096,66.00,66.00 (100.00%)

I assume the difference is bigger if you don't have RDRAND support.

Christoph, Joonsoo: Do you think it would be valuable to add a CONFIG
to disable additional randomization per new page? It will remove
additional entropy but increase performance for machines without arch
specific randomization instructions.

Thanks,
Thomas


On Wed, May 18, 2016 at 7:07 PM, Joonsoo Kim  wrote:
> On Wed, May 18, 2016 at 12:12:13PM -0700, Thomas Garnier wrote:
>> I thought the mix of slab_test & kernbench would show a diverse
>> picture on perf data. Is there another test that you think would be
>> useful?
>
> Single thread testing on slab_test would be meaningful because it also
> touch the slowpath. Problem is just unstable result of slab_test.
>
> You can get more stable result of slab_test if you repeat same test
> sometimes and get average result.
>
> Please use following slab_test. It will do each operations 10
> times and repeat it 50 times.
>
> https://github.com/JoonsooKim/linux/blob/slab_test_robust-next-20160509/mm/slab_test.c
>
> I did a quick test for this patchset and get following result.
>
> - Before (With patch and randomization is disabled by config)
>
> Single thread testing
> =
> 1. Kmalloc: Repeatedly allocate then free test
> 10 times kmalloc(8) -> 42 cycles kfree -> 67 cycles
> 10 times kmalloc(16) -> 43 cycles kfree -> 68 cycles
> 10 times kmalloc(32) -> 47 cycles kfree -> 72 cycles
> 10 times kmalloc(64) -> 54 cycles kfree -> 78 cycles
> 10 times kmalloc(128) -> 75 cycles kfree -> 87 cycles
> 10 times kmalloc(256) -> 84 cycles kfree -> 111 cycles
> 10 times kmalloc(512) -> 82 cycles kfree -> 112 cycles
> 10 times kmalloc(1024) -> 86 cycles kfree -> 113 cycles
> 10 times kmalloc(2048) -> 113 cycles kfree -> 127 cycles
> 10 times kmalloc(4096) -> 151 cycles kfree -> 154 cycles
>
> - After (With patch and randomization is enabled by config)
>
> Single thread testing
> =
> 1. Kmalloc: Repeatedly allocate then free test
> 10 times kmalloc(8) -> 51 cycles kfree -> 68 cycles
> 10 times kmalloc(16) -> 57 cycles kfree -> 70 cycles
> 10 times kmalloc(32) -> 70 cycles kfree -> 75 cycles
> 10 times kmalloc(64) -> 95 cycles kfree -> 84 cycles
> 10 times kmalloc(128) -> 142 cycles kfree -> 97 cycles
> 10 times kmalloc(256) -> 150 cycles kfree -> 107 cycles
> 10 times kmalloc(512) -> 151 cycles kfree -> 107 cycles
> 10 times kmalloc(1024) -> 154 cycles kfree -> 110 cycles
> 10 times kmalloc(2048) -> 230 cycles kfree -> 124 cycles
> 10 times kmalloc(4096) -> 423 cycles kfree -> 165 cycles
>
> It seems that performance decreases a lot but I don't care about it
> because it is a security feature and I don't have a better idea.
>
> Thanks.

Re: [RFC v1 2/2] mm: SLUB Freelist randomization

[Joonsoo Kim]

On Wed, May 18, 2016 at 12:12:13PM -0700, Thomas Garnier wrote:
> I thought the mix of slab_test & kernbench would show a diverse
> picture on perf data. Is there another test that you think would be
> useful?

Single thread testing on slab_test would be meaningful because it also
touch the slowpath. Problem is just unstable result of slab_test.

You can get more stable result of slab_test if you repeat same test
sometimes and get average result.

Please use following slab_test. It will do each operations 10
times and repeat it 50 times.

https://github.com/JoonsooKim/linux/blob/slab_test_robust-next-20160509/mm/slab_test.c

I did a quick test for this patchset and get following result.

- Before (With patch and randomization is disabled by config)

Single thread testing
=
1. Kmalloc: Repeatedly allocate then free test
10 times kmalloc(8) -> 42 cycles kfree -> 67 cycles
10 times kmalloc(16) -> 43 cycles kfree -> 68 cycles
10 times kmalloc(32) -> 47 cycles kfree -> 72 cycles
10 times kmalloc(64) -> 54 cycles kfree -> 78 cycles
10 times kmalloc(128) -> 75 cycles kfree -> 87 cycles
10 times kmalloc(256) -> 84 cycles kfree -> 111 cycles
10 times kmalloc(512) -> 82 cycles kfree -> 112 cycles
10 times kmalloc(1024) -> 86 cycles kfree -> 113 cycles
10 times kmalloc(2048) -> 113 cycles kfree -> 127 cycles
10 times kmalloc(4096) -> 151 cycles kfree -> 154 cycles

- After (With patch and randomization is enabled by config)

Single thread testing
=
1. Kmalloc: Repeatedly allocate then free test
10 times kmalloc(8) -> 51 cycles kfree -> 68 cycles
10 times kmalloc(16) -> 57 cycles kfree -> 70 cycles
10 times kmalloc(32) -> 70 cycles kfree -> 75 cycles
10 times kmalloc(64) -> 95 cycles kfree -> 84 cycles
10 times kmalloc(128) -> 142 cycles kfree -> 97 cycles
10 times kmalloc(256) -> 150 cycles kfree -> 107 cycles
10 times kmalloc(512) -> 151 cycles kfree -> 107 cycles
10 times kmalloc(1024) -> 154 cycles kfree -> 110 cycles
10 times kmalloc(2048) -> 230 cycles kfree -> 124 cycles
10 times kmalloc(4096) -> 423 cycles kfree -> 165 cycles

It seems that performance decreases a lot but I don't care about it
because it is a security feature and I don't have a better idea.

Thanks.

Re: [RFC v1 2/2] mm: SLUB Freelist randomization

[Joonsoo Kim]

On Wed, May 18, 2016 at 12:12:13PM -0700, Thomas Garnier wrote:
> I thought the mix of slab_test & kernbench would show a diverse
> picture on perf data. Is there another test that you think would be
> useful?

Single thread testing on slab_test would be meaningful because it also
touch the slowpath. Problem is just unstable result of slab_test.

You can get more stable result of slab_test if you repeat same test
sometimes and get average result.

Please use following slab_test. It will do each operations 10
times and repeat it 50 times.

https://github.com/JoonsooKim/linux/blob/slab_test_robust-next-20160509/mm/slab_test.c

I did a quick test for this patchset and get following result.

- Before (With patch and randomization is disabled by config)

Single thread testing
=
1. Kmalloc: Repeatedly allocate then free test
10 times kmalloc(8) -> 42 cycles kfree -> 67 cycles
10 times kmalloc(16) -> 43 cycles kfree -> 68 cycles
10 times kmalloc(32) -> 47 cycles kfree -> 72 cycles
10 times kmalloc(64) -> 54 cycles kfree -> 78 cycles
10 times kmalloc(128) -> 75 cycles kfree -> 87 cycles
10 times kmalloc(256) -> 84 cycles kfree -> 111 cycles
10 times kmalloc(512) -> 82 cycles kfree -> 112 cycles
10 times kmalloc(1024) -> 86 cycles kfree -> 113 cycles
10 times kmalloc(2048) -> 113 cycles kfree -> 127 cycles
10 times kmalloc(4096) -> 151 cycles kfree -> 154 cycles

- After (With patch and randomization is enabled by config)

Single thread testing
=
1. Kmalloc: Repeatedly allocate then free test
10 times kmalloc(8) -> 51 cycles kfree -> 68 cycles
10 times kmalloc(16) -> 57 cycles kfree -> 70 cycles
10 times kmalloc(32) -> 70 cycles kfree -> 75 cycles
10 times kmalloc(64) -> 95 cycles kfree -> 84 cycles
10 times kmalloc(128) -> 142 cycles kfree -> 97 cycles
10 times kmalloc(256) -> 150 cycles kfree -> 107 cycles
10 times kmalloc(512) -> 151 cycles kfree -> 107 cycles
10 times kmalloc(1024) -> 154 cycles kfree -> 110 cycles
10 times kmalloc(2048) -> 230 cycles kfree -> 124 cycles
10 times kmalloc(4096) -> 423 cycles kfree -> 165 cycles

It seems that performance decreases a lot but I don't care about it
because it is a security feature and I don't have a better idea.

Thanks.

Re: [RFC v1 2/2] mm: SLUB Freelist randomization

[Thomas Garnier]

I thought the mix of slab_test & kernbench would show a diverse
picture on perf data. Is there another test that you think would be
useful?

Thanks,
Thomas

On Wed, May 18, 2016 at 12:02 PM, Christoph Lameter  wrote:
> On Wed, 18 May 2016, Thomas Garnier wrote:
>
>> Yes, I agree that it is not related to the changes.
>
> Could you please provide meaningful test data?

Re: [RFC v1 2/2] mm: SLUB Freelist randomization

[Thomas Garnier]

I thought the mix of slab_test & kernbench would show a diverse
picture on perf data. Is there another test that you think would be
useful?

Thanks,
Thomas

On Wed, May 18, 2016 at 12:02 PM, Christoph Lameter  wrote:
> On Wed, 18 May 2016, Thomas Garnier wrote:
>
>> Yes, I agree that it is not related to the changes.
>
> Could you please provide meaningful test data?

Re: [RFC v1 2/2] mm: SLUB Freelist randomization

[Christoph Lameter]

On Wed, 18 May 2016, Thomas Garnier wrote:

> Yes, I agree that it is not related to the changes.

Could you please provide meaningful test data?

Re: [RFC v1 2/2] mm: SLUB Freelist randomization

[Christoph Lameter]

On Wed, 18 May 2016, Thomas Garnier wrote:

> Yes, I agree that it is not related to the changes.

Could you please provide meaningful test data?

Re: [RFC v1 2/2] mm: SLUB Freelist randomization

[Thomas Garnier]

Yes, I agree that it is not related to the changes.

On Wed, May 18, 2016 at 11:24 AM, Christoph Lameter  wrote:
> 0.On Wed, 18 May 2016, Thomas Garnier wrote:
>
>> slab_test, before:
>> 1 times kmalloc(8) -> 67 cycles kfree -> 101 cycles
>> 1 times kmalloc(16) -> 68 cycles kfree -> 109 cycles
>> 1 times kmalloc(32) -> 76 cycles kfree -> 119 cycles
>> 1 times kmalloc(64) -> 88 cycles kfree -> 114 cycles
>
>> After:
>> 1 times kmalloc(8) -> 60 cycles kfree -> 74 cycles
>> 1 times kmalloc(16) -> 63 cycles kfree -> 78 cycles
>> 1 times kmalloc(32) -> 72 cycles kfree -> 85 cycles
>> 1 times kmalloc(64) -> 91 cycles kfree -> 99 cycles
>
> Erm... The fastpath was not touched and the tests primarily exercise the
> fastpath. This is likely some artifact of code placement by the compiler?
>

Re: [RFC v1 2/2] mm: SLUB Freelist randomization

[Thomas Garnier]

Yes, I agree that it is not related to the changes.

On Wed, May 18, 2016 at 11:24 AM, Christoph Lameter  wrote:
> 0.On Wed, 18 May 2016, Thomas Garnier wrote:
>
>> slab_test, before:
>> 1 times kmalloc(8) -> 67 cycles kfree -> 101 cycles
>> 1 times kmalloc(16) -> 68 cycles kfree -> 109 cycles
>> 1 times kmalloc(32) -> 76 cycles kfree -> 119 cycles
>> 1 times kmalloc(64) -> 88 cycles kfree -> 114 cycles
>
>> After:
>> 1 times kmalloc(8) -> 60 cycles kfree -> 74 cycles
>> 1 times kmalloc(16) -> 63 cycles kfree -> 78 cycles
>> 1 times kmalloc(32) -> 72 cycles kfree -> 85 cycles
>> 1 times kmalloc(64) -> 91 cycles kfree -> 99 cycles
>
> Erm... The fastpath was not touched and the tests primarily exercise the
> fastpath. This is likely some artifact of code placement by the compiler?
>

Re: [RFC v1 2/2] mm: SLUB Freelist randomization

[Christoph Lameter]

0.On Wed, 18 May 2016, Thomas Garnier wrote:

> slab_test, before:
> 1 times kmalloc(8) -> 67 cycles kfree -> 101 cycles
> 1 times kmalloc(16) -> 68 cycles kfree -> 109 cycles
> 1 times kmalloc(32) -> 76 cycles kfree -> 119 cycles
> 1 times kmalloc(64) -> 88 cycles kfree -> 114 cycles

> After:
> 1 times kmalloc(8) -> 60 cycles kfree -> 74 cycles
> 1 times kmalloc(16) -> 63 cycles kfree -> 78 cycles
> 1 times kmalloc(32) -> 72 cycles kfree -> 85 cycles
> 1 times kmalloc(64) -> 91 cycles kfree -> 99 cycles

Erm... The fastpath was not touched and the tests primarily exercise the
fastpath. This is likely some artifact of code placement by the compiler?

Re: [RFC v1 2/2] mm: SLUB Freelist randomization

[Christoph Lameter]

0.On Wed, 18 May 2016, Thomas Garnier wrote:

> slab_test, before:
> 1 times kmalloc(8) -> 67 cycles kfree -> 101 cycles
> 1 times kmalloc(16) -> 68 cycles kfree -> 109 cycles
> 1 times kmalloc(32) -> 76 cycles kfree -> 119 cycles
> 1 times kmalloc(64) -> 88 cycles kfree -> 114 cycles

> After:
> 1 times kmalloc(8) -> 60 cycles kfree -> 74 cycles
> 1 times kmalloc(16) -> 63 cycles kfree -> 78 cycles
> 1 times kmalloc(32) -> 72 cycles kfree -> 85 cycles
> 1 times kmalloc(64) -> 91 cycles kfree -> 99 cycles

Erm... The fastpath was not touched and the tests primarily exercise the
fastpath. This is likely some artifact of code placement by the compiler?