On 09/03/2013 02:01 AM, Ingo Molnar wrote:
* Waiman Long<waiman.long@xxxxxx> wrote:
Yes, that patch worked. It eliminated the lglock as a bottleneck in
the AIM7 workload. The lg_global_lock did not show up in the perf
profile, whereas the lg_local_lock was only 0.07%.
Just curious: what's the worst bottleneck now in the optimized kernel? :-)
Thanks,
Ingo
With the following patches on v3.11:
1. Linus's version of lockref patch
2. Al's lglock patch
3. My preliminary patch to convert prepend_path under RCU
The perf profile of the kernel portion of the short workload in a
80-core system became like this:
29.87% reaim [kernel.kallsyms] [k] _raw_spin_lock_irqsave
|--50.00%-- tty_ldisc_deref
|--49.01%-- tty_ldisc_try
--0.99%-- [...]
7.55% swapper [kernel.kallsyms] [k] intel_idle
1.03% reaim [kernel.kallsyms] [k] copy_user_generic_string
0.91% reaim [kernel.kallsyms] [k] _raw_spin_lock
|--15.88%-- __rcu_process_callbacks
|--6.55%-- load_balance
|--6.02%-- sem_lock
|--4.77%-- enqueue_to_backlog
|--4.21%-- task_rq_lock
|--3.97%-- process_backlog
|--3.35%-- unix_dgram_sendmsg
|--3.28%-- kmem_cache_free
|--3.16%-- tcp_v4_rcv
|--2.77%-- unix_stream_sendmsg
|--2.36%-- rcu_accelerate_cbs
|--2.02%-- do_wp_page
|--2.02%-- unix_create1
|--1.83%-- unix_peer_get
|--1.67%-- udp_lib_get_port
|--1.66%-- unix_stream_recvmsg
|--1.63%-- handle_pte_fault
|--1.63%-- udp_queue_rcv_skb
|--1.54%-- unix_release_sock
|--1.48%-- try_to_wake_up
|--1.37%-- do_anonymous_page
|--1.37%-- new_inode_pseudo
|--1.33%-- __d_lookup
|--1.20%-- free_one_page
|--1.11%-- __do_fault
|--1.06%-- scheduler_tick
|--0.90%-- __drain_alien_cache
|--0.81%-- inet_csk_get_port
|--0.76%-- sock_alloc
|--0.76%-- shmem_lock
|--0.75%-- __d_instantiate
|--0.70%-- __inet_hash_connect
|--0.69%-- __inet_hash_nolisten
|--0.68%-- ip_local_deliver_finish
|--0.64%-- inet_hash
|--0.64%-- kfree
|--0.60%-- d_path
|--0.58%-- __close_fd
|--0.51%-- evict
--11.76%-- [...]
0.51% reaim [ip_tables] [k] ipt_do_table
0.46% reaim [kernel.kallsyms] [k] __alloc_skb
0.38% reaim [kernel.kallsyms] [k] kfree
0.36% reaim [kernel.kallsyms] [k] kmem_cache_free
0.34% reaim [kernel.kallsyms] [k] system_call_after_swapg
0.32% reaim [kernel.kallsyms] [k] fsnotify
0.32% reaim [kernel.kallsyms] [k] ip_finish_output
0.27% reaim [kernel.kallsyms] [k] system_call
Other than the global tty_ldisc_lock, there is no other major
bottleneck. I am not that worry about the tty_ldisc_lock bottleneck
as real world applications probably won't have that many calls to
set the tty driver.
Regards,
Longman
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
