Messages in this thread | | | Date | Thu, 8 May 2008 15:55:01 -0700 (PDT) | From | Linus Torvalds <> | Subject | Re: [patch] speed up / fix the new generic semaphore code (fix AIM7 40% regression with 2.6.26-rc1) |
| |
On Thu, 8 May 2008, Ingo Molnar wrote: > > 2512 down <= lock_kernel <= opost <= write_chan < > 2574 down <= lock_kernel <= write_chan <= tty_write <
Ok. tty write handling. Nasty. But not as nasty as the open/close code, perhaps, and maybe we'll get it fixed some day.
In fact, I thought we had fixed most of this already, but hey, I was clearly wrong. I assume Alan looks at it occasionally and groans. Alan?
> > some other interesting stats. Top wakeups sources: > > [...] > 1301 default_wake_function <= __wake_up_common <= __wake_up <= n_tty_receive_buf <= pty_write <= write_chan < > 2065 wake_up_state <= prepare_signal <= send_signal <= __group_send_sig_info <= group_send_sig_info <= __kill_pgrp_info <
Ok, signals being the top one, but that tty code is pretty high again.
> and here's a few seconds worth of NMI driven readprofile output: > > 216021 sync_page 3375.3281 > 391888 page_check_address 1414.7581 > 962212 total 0.3039 > > system overhead is consistently 20% during this test. > > the page_check_address() overhead is surprising - tons of rmap > contention? about 10% wall-clock overhead in that function alone - and > this is just on a dual-core box!
No, it's not rmap contention. Your profile hits are just on the actual calculations, and it's all data-dependent arithmetic and loads. Some cache misses on the page tables, clearly, but it looks like a lot of it is even just the plain arithmetic (the imul followed by a data-dependent 'lea' instruction).
Some of it is that "page_to_pfn(page)", which involves a nasty division (divide by sizeof(struct page)). It gets turned into that shift and multiply, but it's still quite expensive with big constants etc.
Linus
| |