senozhatsky

The actual allocation happens in memset() - because this is where the application page faults and jumps to the kernel. The kernel populates application's address space and returns back to user land. This surely can add a lot of noise to the test results. free() is also not very simple anymore considering all the madvise() magic it does.

It probably would be interesting to see how many page faults the application generates with tcmalloc/jemalloc/glibc/etc allocators.

-ss

Seems that VirtualAlloc() [1] is a little bit closer to madvise(), but still is pretty far. madvise() is quite powerful. For instance, take a look at MADV_FREE.

[1] https://msdn.microsoft.com/en-us/library/windows/desktop/aa3...

-ss

A followup: zswap THP support is not implemented yet. Huang Ying agreed that it would be interesting to have it, but it's not on his TODO list as of now.

-ss

He also mentions:

> Richard Brodie's published books include:

> Virus of the Mind: The New Science of the Meme

http://www.memecentral.com/votm.htm

I regret I clicked...

-ss

> but what kind of Real World workload or environment would one need to be in to see this in action?

Hmm, Facebook perhaps.

Emedded devices tend to use zswap/zram which [yet] don't support THP, as far as I know. For instance, take a look at zswap_frontswap_store():

         /* THP isn't supported */ 
         if (PageTransHuge(page)) { 
                 ret = -EINVAL; 
                 goto reject; 
         } 

Once zswap [and, perhaps, zram] gain THP swap out/in support, embedded devices [some of which use swap quite heavily] should also see a considerable performance improvement.

P.S. I didn't check the patch set, may be zswap THP support is already in there.

-ss

Right. I'm one of those always-grumpy guys. I totally dislike (um... hate actually) the idea of open workspace.

> I am concerned about providing a librseq that handles rseq registration for early adopters though

Sounds very reasonable.

So at this point, as far as I understand it, FB and Google carry in-house rseq kernel and user space patches. Right? Are they on board with the mainline rseq? Will FB support rseq in jemalloc any time soon?

-ss

Hi Mathieu, Yep, was going to say, that the patch set has evolved rather notably. Good job.

Did you manage to push the required changes to glibc or do you maintain your own user space rseq lib?

-ss

> That answer with the long unnecessary dump completely misses what I asked for.

Yeah, I guess you are right. Sorry for the noise.

/* p.s. I didn't vote down your comment */

The kernel does use PAUSE // f390

objdump -d vmlinux.o | grep -c "f3 90"

245

e.g.

00000000000683a0 <__task_rq_lock>:

   683a0:       e8 00 00 00 00          callq  683a5 <__task_rq_lock+0x5>
   683a5:       55                      push   %rbp
   683a6:       48 89 e5                mov    %rsp,%rbp
   683a9:       41 56                   push   %r14
   683ab:       49 c7 c6 00 00 00 00    mov    $0x0,%r14
   683b2:       41 55                   push   %r13
   683b4:       49 89 fd                mov    %rdi,%r13
   683b7:       41 54                   push   %r12
   683b9:       53                      push   %rbx
   683ba:       48 c7 c3 00 00 00 00    mov    $0x0,%rbx
   683c1:       41 8b 45 3c             mov    0x3c(%r13),%eax
   683c5:       4d 8b 24 c6             mov    (%r14,%rax,8),%r12
   683c9:       49 01 dc                add    %rbx,%r12
   683cc:       4c 89 e7                mov    %r12,%rdi
   683cf:       e8 00 00 00 00          callq  683d4 <__task_rq_lock+0x34>
   683d4:       41 8b 45 3c             mov    0x3c(%r13),%eax
   683d8:       49 8b 14 c6             mov    (%r14,%rax,8),%rdx
   683dc:       48 01 da                add    %rbx,%rdx
   683df:       49 39 d4                cmp    %rdx,%r12
   683e2:       75 13                   jne    683f7 <__task_rq_lock+0x57>
   683e4:       41 83 7d 60 02          cmpl   $0x2,0x60(%r13)
   683e9:       74 0c                   je     683f7 <__task_rq_lock+0x57>
   683eb:       5b                      pop    %rbx
   683ec:       4c 89 e0                mov    %r12,%rax
   683ef:       41 5c                   pop    %r12
   683f1:       41 5d                   pop    %r13
   683f3:       41 5e                   pop    %r14
   683f5:       5d                      pop    %rbp
   683f6:       c3                      retq   
   683f7:       4c 89 e7                mov    %r12,%rdi
   683fa:       e8 00 00 00 00          callq  683ff <__task_rq_lock+0x5f>
   683ff:       41 83 7d 60 02          cmpl   $0x2,0x60(%r13)
   68404:       75 bb                   jne    683c1 <__task_rq_lock+0x21>
   68406:       f3 90                   pause  
   68408:       41 83 7d 60 02          cmpl   $0x2,0x60(%r13)
   6840d:       75 b2                   jne    683c1 <__task_rq_lock+0x21>
   6840f:       eb f5                   jmp    68406 <__task_rq_lock+0x66>
   68411:       0f 1f 44 00 00          nopl   0x0(%rax,%rax,1)
   68416:       66 2e 0f 1f 84 00 00    nopw   %cs:0x0(%rax,%rax,1)
   6841d:       00 00 00

that pause should be:

                  while (unlikely(task_on_rq_migrating(p)))                       
                          cpu_relax();                                            

   -ss

"This page was last edited on 23 January 2017, at 15:28."