Seem that redhat rhev hava a tunable value to enable|disable THP

http://200.1.19.60/ovirt-engine/docs/manual/en_US/pdf/Technical_Guide/Red_Hat_Enterprise_Virtualization-Technical_Guide.pdf

Maybe could we could add option in datacenter.cfg,

and enable|disable early at boot with a systemd unit


I need to test, but this systemd unit should work I think

"
disable-transparent-huge-pages.service

[Unit]
Description=Disable transparent huge pages

[Service]
Type=oneshot
DefaultDependencies=no
ExecStart=/bin/sh -c "/usr/bin/echo never | /usr/bin/tee 
/sys/kernel/mm/transparent_hugepage/enabled"
ExecStart=/bin/sh -c "/usr/bin/echo never | /usr/bin/tee 
/sys/kernel/mm/transparent_hugepage/defrag"
After=sysinit.target local-fs.target
Before=base.target


[Install]
WantedBy=base.target
"

(seem that defrag need also to be explicitly disabled, from the differents doc 
I have found )



It's also possible to setup GRUB_CMDLINE_LINUX="transparent_hugepage=never" for 
grub at boot,
but they are no option for defrag.

(I don't have find any official information about defrag value, if disabling 
transparent_hugepage is disabling defrag too)


----- Mail original -----
De: "aderumier" <[email protected]>
À: "Andreas Steinel" <[email protected]>
Cc: "pve-devel" <[email protected]>
Envoyé: Mercredi 9 Septembre 2015 19:30:24
Objet: Re: [pve-devel] disabling transparent hugepage by default like kernel 
2.6.32 ?

Do you have tested it with a real workload and big memory ? (100-200GB for 
example). 

I'm curious to see what happen with a lot of alloc/desalloc and fragmentation. 


----- Mail original ----- 
De: "Andreas Steinel" <[email protected]> 
À: "aderumier" <[email protected]> 
Cc: "Daniel Hunsaker" <[email protected]>, "dietmar" <[email protected]>, 
"pve-devel" <[email protected]> 
Envoyé: Mercredi 9 Septembre 2015 18:41:37 
Objet: Re: [pve-devel] disabling transparent hugepage by default like kernel 
2.6.32 ? 

I tried with a simple 128 MB Jessie Box and 'mbw' program and got these 
results: 

mbw -n 100 50 | grep AVG > hthp_1_gthp_1 



HostTransparentHugePages_(1|0)_GuestTransparentHugePages_(1|0) 


Test hthp_0_gthp_0 
AVG Method: MEMCPY Elapsed: 0.01728 MiB: 50.00000 Copy: 
2893.123 MiB/s 
AVG Method: DUMB Elapsed: 0.01770 MiB: 50.00000 Copy: 
2824.581 MiB/s 
AVG Method: MCBLOCK Elapsed: 0.01111 MiB: 50.00000 Copy: 
4499.575 MiB/s 
Test hthp_0_gthp_1 
AVG Method: MEMCPY Elapsed: 0.01927 MiB: 50.00000 Copy: 
2594.132 MiB/s 
AVG Method: DUMB Elapsed: 0.01869 MiB: 50.00000 Copy: 
2674.970 MiB/s 
AVG Method: MCBLOCK Elapsed: 0.01157 MiB: 50.00000 Copy: 
4322.956 MiB/s 
Test hthp_1_gthp_0 
AVG Method: MEMCPY Elapsed: 0.01645 MiB: 50.00000 Copy: 
3039.115 MiB/s 
AVG Method: DUMB Elapsed: 0.01572 MiB: 50.00000 Copy: 
3180.148 MiB/s 
AVG Method: MCBLOCK Elapsed: 0.00987 MiB: 50.00000 Copy: 
5066.072 MiB/s 
Test hthp_1_gthp_1 
AVG Method: MEMCPY Elapsed: 0.02151 MiB: 50.00000 Copy: 
2324.526 MiB/s 
AVG Method: DUMB Elapsed: 0.01553 MiB: 50.00000 Copy: 
3220.203 MiB/s 
AVG Method: MCBLOCK Elapsed: 0.00998 MiB: 50.00000 Copy: 
5009.729 MiB/s 

On Wed, Sep 9, 2015 at 5:43 PM, Alexandre DERUMIER <[email protected]> wrote: 
>>>In my benchmarks, THP increase the memory transaction speed by 5-10% in the 
>>>KVM guest if THP is activated on the host side, not in the VM side. I know 
>>>that THP for databases is bad, but we are not using THP in the guest >>where 
>>>the database lives. Can someone provide some benchmarks for that case or 
>>>further information? Any suggestions? 
> 
> Oh, good to known. 
> 
> How much memory do you use it your vm ? what is the database software ? 
> 
> ----- Mail original ----- 
> De: "Andreas Steinel" <[email protected]> 
> À: "Daniel Hunsaker" <[email protected]> 
> Cc: "aderumier" <[email protected]>, "dietmar" <[email protected]>, 
> "pve-devel" <[email protected]> 
> Envoyé: Mercredi 9 Septembre 2015 16:32:23 
> Objet: Re: [pve-devel] disabling transparent hugepage by default like kernel 
> 2.6.32 ? 
> 
> Hi, 
> In my benchmarks, THP increase the memory transaction speed by 5-10% in the 
> KVM guest if THP is activated on the host side, not in the VM side. I know 
> that THP for databases is bad, but we are not using THP in the guest where 
> the database lives. Can someone provide some benchmarks for that case or 
> further information? Any suggestions? 
> 
> On Wed, Sep 9, 2015 at 3:45 PM, Daniel Hunsaker < [email protected] > 
> wrote: 
> 
> 
> 
> 
> What about setting CONFIG_TRANSPARENT_HUGEPAGE_ALWAYS = N? As I understand 
> it, "not set" means "use the default setting the kernel devs think is the 
> most sane for normal use", which in this case would be Y... 
> 
> On Wed, Sep 9, 2015, 06:58 Alexandre DERUMIER < [email protected] > wrote: 
> 
> 
>>>I could set it in kernel config, for example: 
>>> 
>>>CONFIG_TRANSPARENT_HUGEPAGE_MADVISE=y 
>>> 
>>>would that help? 
> 
> Well, this is like "echo madvise > 
> /sys/kernel/mm/transparent_hugepage/enabled" 
> 
> But I don't see how to set never. 
> 
> maybe 
> 
> # CONFIG_TRANSPARENT_HUGEPAGE_ALWAYS is not set 
> # CONFIG_TRANSPARENT_HUGEPAGE_MADVISE is not set 
> 
> 
> But I don't known how to unset CONFIG_TRANSPARENT_HUGEPAGE_ALWAYS in the new 
> pve-kernel package makefile ? 
> 
> 
> I have tried to add 
> 
> PVE_CONFIG_OPTS= \ 
> .. 
> -d CONFIG_TRANSPARENT_HUGEPAGE_ALWAYS \ 
> .. 
> 
> but it don't seem to work, I still have CONFIG_TRANSPARENT_HUGEPAGE_ALWAYS=Y 
> in .config 
> 
> Any idea ? 
> 
> 
> 
> ----- Mail original ----- 
> De: "dietmar" < [email protected] > 
> À: "aderumier" < [email protected] >, "pve-devel" < 
> [email protected] > 
> Envoyé: Mercredi 9 Septembre 2015 06:33:05 
> Objet: Re: [pve-devel] disabling transparent hugepage by default like kernel 
> 2.6.32 ? 
> 
>> I think it's better to disable it by default. 
>> 
>> echo never > /sys/kernel/mm/transparent_hugepage/enabled. 
>> 
>> (I don't known what is the best way to disable it by default) 
> 
> I could set it in kernel config, for example: 
> 
> CONFIG_TRANSPARENT_HUGEPAGE_MADVISE=y 
> 
> would that help? 
> _______________________________________________ 
> pve-devel mailing list 
> [email protected] 
> http://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel 
> 
> 
> 
> 
> _______________________________________________ 
> pve-devel mailing list 
> [email protected] 
> http://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel 
> 
> 
> 
> 

_______________________________________________ 
pve-devel mailing list 
[email protected] 
http://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel 
_______________________________________________
pve-devel mailing list
[email protected]
http://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel

Reply via email to