Your answer makes a lot of sense. It makes it the 'transparent' part clear.
What doesn't make sense is why the kernel would decide to switch between large/small pages. So what is the benefit to let a process go through the pain of this conversion? Will it resize in both directions? On Monday, August 7, 2017 at 6:55:05 PM UTC+3, Marshall Pierce wrote: > > AFAIK, The issue is not huge pages that applications opt in to and > control; it's when they are "transparent", as in when the kernel > "helpfully" decides when to use them. This can lead to significant > pauses as the kernel decides that now is the time to rearrange your > process's memory to be more or less huge-page-y. I have experienced this > even with desktop java apps with relatively small heaps. > > You can look for CONFIG_TRANSPARENT_HUGEPAGE in your kernel config. > > -Marshall > > On 08/07/2017 10:42 AM, Peter Veentjer wrote: > > Hi Everyone, > > > > I have a failing understanding the problem with transparent huge pages. > > > > I 'understand' how normal pages work. A page is typically 4kb in a > > virtual address space; each process has its own. > > > > I understand how the TLB fits in; a cache providing a mapping of virtual > > to real addresses to speed up address conversion. > > > > I understand that using a large page e.g. 2mb instead of a 4kb page can > > reduce pressure on the TLB. > > > > So till so far it looks like huge large pages makes a lot of sense; of > > course at the expensive of wasting memory if only a small section of a > > page is being used. > > > > The first part I don't understand is: why is it called transparent huge > > pages? So what is transparent about it? > > > > The second part I'm failing to understand is: why can it cause problems? > > There are quite a few applications that recommend disabling THP and I > > recently helped a customer that was helped by disabling it. It seems > > there is more going on behind the scene's than having an increased page > > size. Is it caused due to fragmentation? So if a new page is needed and > > memory is fragmented (due to smaller pages); that these pages need to be > > compacted before a new page can be allocated? > > > > -- > > You received this message because you are subscribed to the Google > > Groups "mechanical-sympathy" group. > > To unsubscribe from this group and stop receiving emails from it, send > > an email to mechanical-sympathy+unsubscr...@googlegroups.com > <javascript:> > > <mailto:mechanical-sympathy+unsubscr...@googlegroups.com <javascript:>>. > > > For more options, visit https://groups.google.com/d/optout. > > -- You received this message because you are subscribed to the Google Groups "mechanical-sympathy" group. To unsubscribe from this group and stop receiving emails from it, send an email to mechanical-sympathy+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
