2006-02-23 13:19:27

by Arjan van de Ven

[permalink] [raw]
Subject: Patch to make the head.S-must-be-first-in-vmlinux order explicit

This patch puts the code from head.S in a special .bootstrap.text
section.

I'm working on a patch to reorder the functions in the kernel (I'll post
that later), but for x86-64 at least the kernel bootstrap requires that the
head.S functions are on the very first page/pages of the kernel text. This
is understandable since the bootstrap is complex enough already and not a
problem at all, it just means they aren't allowed to be reordered. This
patch puts these special functions into a separate section to document this,
and to guarantee this in the light of possibly reordering the rest later.

(So this patch doesn't fix a bug per se, but makes things more robust by
making the order of these functions explicit)

Signed-off-by: Arjan van de Ven <[email protected]>
---
arch/x86_64/kernel/head.S | 1 +
arch/x86_64/kernel/vmlinux.lds.S | 1 +
2 files changed, 2 insertions(+)

Index: linux-2.6.16-reorder/arch/x86_64/kernel/head.S
===================================================================
--- linux-2.6.16-reorder.orig/arch/x86_64/kernel/head.S
+++ linux-2.6.16-reorder/arch/x86_64/kernel/head.S
@@ -26,6 +26,7 @@
*/

.text
+ .section .bootstrap.text
.code32
.globl startup_32
/* %bx: 1 if coming from smp trampoline on secondary cpu */
Index: linux-2.6.16-reorder/arch/x86_64/kernel/vmlinux.lds.S
===================================================================
--- linux-2.6.16-reorder.orig/arch/x86_64/kernel/vmlinux.lds.S
+++ linux-2.6.16-reorder/arch/x86_64/kernel/vmlinux.lds.S
@@ -20,6 +20,7 @@ SECTIONS
phys_startup_64 = startup_64 - LOAD_OFFSET;
_text = .; /* Text and read-only data */
.text : AT(ADDR(.text) - LOAD_OFFSET) {
+ *(.bootstrap.text)
*(.text)
SCHED_TEXT
LOCK_TEXT


2006-02-23 13:42:26

by Andi Kleen

[permalink] [raw]
Subject: Re: Patch to make the head.S-must-be-first-in-vmlinux order explicit

On Thursday 23 February 2006 14:19, Arjan van de Ven wrote:
> This patch puts the code from head.S in a special .bootstrap.text
> section.
>
> I'm working on a patch to reorder the functions in the kernel (I'll post
> that later), but for x86-64 at least the kernel bootstrap requires that the
> head.S functions are on the very first page/pages of the kernel text. This
> is understandable since the bootstrap is complex enough already and not a
> problem at all, it just means they aren't allowed to be reordered. This
> patch puts these special functions into a separate section to document this,
> and to guarantee this in the light of possibly reordering the rest later.
>
> (So this patch doesn't fix a bug per se, but makes things more robust by
> making the order of these functions explicit)

I don't think the 64bit kernel code requires this actually (or at least
it shouldn't), but arch/x86_64/boot/compressed/head.S
seems to have the entry address hardcoded. Perhaps you can just change this
to pass in the right address?

-Andi

2006-02-23 13:57:56

by Arjan van de Ven

[permalink] [raw]
Subject: Re: Patch to make the head.S-must-be-first-in-vmlinux order explicit

Andi Kleen wrote:
> On Thursday 23 February 2006 14:19, Arjan van de Ven wrote:
>> This patch puts the code from head.S in a special .bootstrap.text
>> section.
>>
>> I'm working on a patch to reorder the functions in the kernel (I'll post
>> that later), but for x86-64 at least the kernel bootstrap requires that the
>> head.S functions are on the very first page/pages of the kernel text. This
>> is understandable since the bootstrap is complex enough already and not a
>> problem at all, it just means they aren't allowed to be reordered. This
>> patch puts these special functions into a separate section to document this,
>> and to guarantee this in the light of possibly reordering the rest later.
>>
>> (So this patch doesn't fix a bug per se, but makes things more robust by
>> making the order of these functions explicit)
>
> I don't think the 64bit kernel code requires this actually

It didn't boot at first until I fixed this ;)

> (or at least
> it shouldn't), but arch/x86_64/boot/compressed/head.S
> seems to have the entry address hardcoded. Perhaps you can just change this
> to pass in the right address?

the issue is that the address will be a link time thing, which means
lots of complexity. and it's only a handful of functions, so pinning
these few explicitly looked to me like the best simple solution (eg
anything else will be fragile and failures in this area are near
impossible to debug, even when it'll work now complexity means it may
fail in the future ;( )

2006-02-23 14:31:39

by Andi Kleen

[permalink] [raw]
Subject: Re: Patch to make the head.S-must-be-first-in-vmlinux order explicit

On Thursday 23 February 2006 14:57, Arjan van de Ven wrote:

> > (or at least
> > it shouldn't), but arch/x86_64/boot/compressed/head.S
> > seems to have the entry address hardcoded. Perhaps you can just change this
> > to pass in the right address?
>
> the issue is that the address will be a link time thing, which means
> lots of complexity.

bzImage image should be only generated after vmlinux is done
and then the address should be available with a simple grep in System.map

-Andi

2006-02-23 14:40:41

by Arjan van de Ven

[permalink] [raw]
Subject: Re: Patch to make the head.S-must-be-first-in-vmlinux order explicit

Andi Kleen wrote:
> On Thursday 23 February 2006 14:57, Arjan van de Ven wrote:
>
>>> (or at least
>>> it shouldn't), but arch/x86_64/boot/compressed/head.S
>>> seems to have the entry address hardcoded. Perhaps you can just change this
>>> to pass in the right address?
>> the issue is that the address will be a link time thing, which means
>> lots of complexity.
>
> bzImage image should be only generated after vmlinux is done
> and then the address should be available with a simple grep in System.map
>

ok I'll look into this and see if the result is reasonable

2006-02-23 15:09:35

by Arjan van de Ven

[permalink] [raw]
Subject: Patch to reorder functions in the vmlinux to a defined order

This patch puts the infrastructure in place to allow for a reordering of
functions based inside the vmlinux. The general idea is that it is possible
to put all "common" functions into the first 2Mb of the code, so that they
are covered by one TLB entry. This as opposed to the current situation where
a typical vmlinux covers about 3.5Mb (on x86-64) and thus 2 TLB entries.
(This patch depends on the previous patch to pin head.S as first in the order)

This is done by enabling the -ffunction-sections flag in gcc, which puts
each function in its own ELF section, so that the linker can then order them
in a way defined by the linker script.

As per previous discussions, Linus said he wanted a "static" list for this,
eg a list provided by the kernel tarbal, so that most people have the same
ordering at least. A script is provided to create this list based on
readprofile(1) output. The included list is provisional, and entirely biased
on my own testbox and me running a few kernel compiles and some other
things.

I think that to get to a better list we need to invite people to submit
their own profiles, and somehow add those all up and base the final list on
that. I'm willing to do that effort if this is ends up being the prefered
approach. Such an effort probably needs to be repeated like once a year or
so to adopt to the changing nature of the kernel.

Signed-off-by: Arjan van de Ven <[email protected]>

---
arch/x86_64/Makefile | 1
arch/x86_64/kernel/vmlinux.lds.S | 5
scripts/functionlist | 1286 +++++++++++++++++++++++++++++++++++++++
scripts/profile2linkerlist.pl | 21
4 files changed, 1313 insertions(+)

Index: linux-2.6.16-reorder/arch/x86_64/Makefile
===================================================================
--- linux-2.6.16-reorder.orig/arch/x86_64/Makefile
+++ linux-2.6.16-reorder/arch/x86_64/Makefile
@@ -35,6 +35,7 @@ CFLAGS += -m64
CFLAGS += -mno-red-zone
CFLAGS += -mcmodel=kernel
CFLAGS += -pipe
+CFLAGS += -ffunction-sections
# this makes reading assembly source easier, but produces worse code
# actually it makes the kernel smaller too.
CFLAGS += -fno-reorder-blocks
Index: linux-2.6.16-reorder/arch/x86_64/kernel/vmlinux.lds.S
===================================================================
--- linux-2.6.16-reorder.orig/arch/x86_64/kernel/vmlinux.lds.S
+++ linux-2.6.16-reorder/arch/x86_64/kernel/vmlinux.lds.S
@@ -20,7 +20,12 @@ SECTIONS
phys_startup_64 = startup_64 - LOAD_OFFSET;
_text = .; /* Text and read-only data */
.text : AT(ADDR(.text) - LOAD_OFFSET) {
+ /* First the code that has to be first for bootstrapping */
*(.bootstrap.text)
+ /* Then all the functions that are "hot" in profiles, to group them
+ onto the same hugetlb entry */
+ #include "../../../scripts/functionlist"
+ /* Then the rest */
*(.text)
SCHED_TEXT
LOCK_TEXT
Index: linux-2.6.16-reorder/scripts/functionlist
===================================================================
--- /dev/null
+++ linux-2.6.16-reorder/scripts/functionlist
@@ -0,0 +1,1286 @@
+*(.text.flush_thread)
+*(.text.check_poison_obj)
+*(.text.copy_page)
+*(.text.__set_personality)
+*(.text.gart_map_sg)
+*(.text.kmem_cache_free)
+*(.text.find_get_page)
+*(.text._raw_spin_lock)
+*(.text.ide_outb)
+*(.text.unmap_vmas)
+*(.text.copy_page_range)
+*(.text.kprobe_handler)
+*(.text.__handle_mm_fault)
+*(.text.__d_lookup)
+*(.text.copy_user_generic)
+*(.text.__link_path_walk)
+*(.text.get_page_from_freelist)
+*(.text.kmem_cache_alloc)
+*(.text.drive_cmd_intr)
+*(.text.ia32_setup_sigcontext)
+*(.text.huge_pte_offset)
+*(.text.do_page_fault)
+*(.text.page_remove_rmap)
+*(.text.release_pages)
+*(.text.ide_end_request)
+*(.text.__mutex_lock_slowpath)
+*(.text.__find_get_block)
+*(.text.kfree)
+*(.text.vfs_read)
+*(.text._raw_spin_unlock)
+*(.text.free_hot_cold_page)
+*(.text.fget_light)
+*(.text.schedule)
+*(.text.memcmp)
+*(.text.touch_atime)
+*(.text.__might_sleep)
+*(.text.__down_read_trylock)
+*(.text.arch_pick_mmap_layout)
+*(.text.find_vma)
+*(.text.__make_request)
+*(.text.do_generic_mapping_read)
+*(.text.mutex_lock_interruptible)
+*(.text.__generic_file_aio_read)
+*(.text._atomic_dec_and_lock)
+*(.text.__wake_up_bit)
+*(.text.add_to_page_cache)
+*(.text.cache_alloc_debugcheck_after)
+*(.text.vm_normal_page)
+*(.text.mutex_debug_check_no_locks_freed)
+*(.text.net_rx_action)
+*(.text.__find_first_zero_bit)
+*(.text.put_page)
+*(.text._raw_read_lock)
+*(.text.__delay)
+*(.text.dnotify_parent)
+*(.text.do_path_lookup)
+*(.text.do_sync_read)
+*(.text.do_lookup)
+*(.text.bit_waitqueue)
+*(.text.file_read_actor)
+*(.text.strncpy_from_user)
+*(.text.__pagevec_lru_add_active)
+*(.text.fget)
+*(.text.dput)
+*(.text.__strnlen_user)
+*(.text.inotify_inode_queue_event)
+*(.text.rw_verify_area)
+*(.text.ide_intr)
+*(.text.inotify_dentry_parent_queue_event)
+*(.text.permission)
+*(.text.memscan)
+*(.text.hpet_rtc_interrupt)
+*(.text.do_mmap_pgoff)
+*(.text.current_fs_time)
+*(.text.vfs_getattr)
+*(.text.kmem_flagcheck)
+*(.text.mark_page_accessed)
+*(.text.free_pages_and_swap_cache)
+*(.text.generic_fillattr)
+*(.text.__block_prepare_write)
+*(.text.__set_page_dirty_nobuffers)
+*(.text.link_path_walk)
+*(.text.find_get_pages_tag)
+*(.text.ide_do_request)
+*(.text.__alloc_pages)
+*(.text.generic_permission)
+*(.text.mod_page_state_offset)
+*(.text.free_pgd_range)
+*(.text.generic_file_buffered_write)
+*(.text.number)
+*(.text.ide_do_rw_disk)
+*(.text.__brelse)
+*(.text.__mod_page_state_offset)
+*(.text.rotate_reclaimable_page)
+*(.text.find_vma_prepare)
+*(.text.find_vma_prev)
+*(.text.lru_cache_add_active)
+*(.text.__kmalloc_track_caller)
+*(.text.smp_invalidate_interrupt)
+*(.text.handle_IRQ_event)
+*(.text.__find_get_block_slow)
+*(.text.do_wp_page)
+*(.text.do_select)
+*(.text.set_user_nice)
+*(.text.sys_read)
+*(.text.do_munmap)
+*(.text.csum_partial)
+*(.text.__do_softirq)
+*(.text.may_open)
+*(.text.getname)
+*(.text.get_empty_filp)
+*(.text.__fput)
+*(.text.remove_mapping)
+*(.text.filp_ctor)
+*(.text.poison_obj)
+*(.text.unmap_region)
+*(.text.test_set_page_writeback)
+*(.text.__do_page_cache_readahead)
+*(.text.sock_def_readable)
+*(.text.ide_outl)
+*(.text.shrink_zone)
+*(.text.rb_insert_color)
+*(.text.get_request)
+*(.text.sys_pread64)
+*(.text.spin_bug)
+*(.text.ide_outsl)
+*(.text.mask_and_ack_8259A)
+*(.text.filemap_nopage)
+*(.text.page_add_file_rmap)
+*(.text.find_lock_page)
+*(.text.tcp_poll)
+*(.text.__mark_inode_dirty)
+*(.text.file_ra_state_init)
+*(.text.generic_file_llseek)
+*(.text.__pagevec_lru_add)
+*(.text.page_cache_readahead)
+*(.text.n_tty_receive_buf)
+*(.text.zonelist_policy)
+*(.text.vma_adjust)
+*(.text.test_clear_page_dirty)
+*(.text.sync_buffer)
+*(.text.do_exit)
+*(.text.__bitmap_weight)
+*(.text.alloc_pages_current)
+*(.text.get_unused_fd)
+*(.text.zone_watermark_ok)
+*(.text.cpuset_update_task_memory_state)
+*(.text.__bitmap_empty)
+*(.text.sys_munmap)
+*(.text.__inode_dir_notify)
+*(.text.__generic_file_aio_write_nolock)
+*(.text.__pte_alloc)
+*(.text.sys_select)
+*(.text.vm_acct_memory)
+*(.text.vfs_write)
+*(.text.__lru_add_drain)
+*(.text.prio_tree_insert)
+*(.text.generic_file_aio_read)
+*(.text.vma_merge)
+*(.text.block_write_full_page)
+*(.text.__page_set_anon_rmap)
+*(.text.apic_timer_interrupt)
+*(.text.release_console_sem)
+*(.text.sys_write)
+*(.text.sys_brk)
+*(.text.dup_mm)
+*(.text.read_current_timer)
+*(.text.ll_rw_block)
+*(.text.blk_rq_map_sg)
+*(.text.dbg_userword)
+*(.text.__block_commit_write)
+*(.text.cache_grow)
+*(.text.copy_strings)
+*(.text.release_task)
+*(.text.do_sync_write)
+*(.text.unlock_page)
+*(.text.load_elf_binary)
+*(.text.__follow_mount)
+*(.text.__getblk)
+*(.text.do_sys_open)
+*(.text.current_kernel_time)
+*(.text.call_rcu)
+*(.text.write_chan)
+*(.text.vsnprintf)
+*(.text.dummy_inode_setsecurity)
+*(.text.submit_bh)
+*(.text.poll_freewait)
+*(.text.bio_alloc_bioset)
+*(.text.skb_clone)
+*(.text.page_waitqueue)
+*(.text.__mutex_lock_interruptible_slowpath)
+*(.text.get_index)
+*(.text.csum_partial_copy_generic)
+*(.text.bad_range)
+*(.text.remove_vma)
+*(.text.cp_new_stat)
+*(.text.alloc_arraycache)
+*(.text.test_clear_page_writeback)
+*(.text.strsep)
+*(.text.open_namei)
+*(.text._raw_read_unlock)
+*(.text.get_vma_policy)
+*(.text.__down_write_trylock)
+*(.text.find_get_pages)
+*(.text.tcp_rcv_established)
+*(.text.generic_make_request)
+*(.text.__block_write_full_page)
+*(.text.cfq_set_request)
+*(.text.sys_inotify_init)
+*(.text.split_vma)
+*(.text.__mod_timer)
+*(.text.get_options)
+*(.text.vma_link)
+*(.text.mpage_writepages)
+*(.text.truncate_complete_page)
+*(.text.tcp_recvmsg)
+*(.text.sigprocmask)
+*(.text.filemap_populate)
+*(.text.sys_close)
+*(.text.inotify_dev_queue_event)
+*(.text.do_task_stat)
+*(.text.__dentry_open)
+*(.text.unlink_file_vma)
+*(.text.__pollwait)
+*(.text.packet_rcv_spkt)
+*(.text.drop_buffers)
+*(.text.free_pgtables)
+*(.text.generic_file_direct_write)
+*(.text.copy_process)
+*(.text.netif_receive_skb)
+*(.text.dnotify_flush)
+*(.text.print_bad_pte)
+*(.text.anon_vma_unlink)
+*(.text.sys_mprotect)
+*(.text.sync_sb_inodes)
+*(.text.find_inode_fast)
+*(.text.dummy_inode_readlink)
+*(.text.putname)
+*(.text.init_smp_flush)
+*(.text.dbg_redzone2)
+*(.text.sk_run_filter)
+*(.text.may_expand_vm)
+*(.text.generic_file_aio_write)
+*(.text.find_next_zero_bit)
+*(.text.file_kill)
+*(.text.audit_getname)
+*(.text.arch_unmap_area_topdown)
+*(.text.alloc_page_vma)
+*(.text.tcp_transmit_skb)
+*(.text.rb_next)
+*(.text.dbg_redzone1)
+*(.text.generic_file_mmap)
+*(.text.vfs_fstat)
+*(.text.sys_time)
+*(.text.page_lock_anon_vma)
+*(.text.get_unmapped_area)
+*(.text.remote_llseek)
+*(.text.__up_read)
+*(.text.fd_install)
+*(.text.eventpoll_init_file)
+*(.text.dma_alloc_coherent)
+*(.text.create_empty_buffers)
+*(.text.__mutex_unlock_slowpath)
+*(.text.dup_fd)
+*(.text.d_alloc)
+*(.text.tty_ldisc_try)
+*(.text.sys_stime)
+*(.text.__rb_rotate_right)
+*(.text.d_validate)
+*(.text.rb_erase)
+*(.text.path_release)
+*(.text.memmove)
+*(.text.invalidate_complete_page)
+*(.text.clear_inode)
+*(.text.cache_estimate)
+*(.text.alloc_buffer_head)
+*(.text.smp_call_function_interrupt)
+*(.text.flush_tlb_others)
+*(.text.file_move)
+*(.text.balance_dirty_pages_ratelimited)
+*(.text.vma_prio_tree_add)
+*(.text.timespec_trunc)
+*(.text.mempool_alloc)
+*(.text.iget_locked)
+*(.text.d_alloc_root)
+*(.text.cpuset_populate_dir)
+*(.text.anon_vma_prepare)
+*(.text.sys_newstat)
+*(.text.alloc_page_interleave)
+*(.text.__path_lookup_intent_open)
+*(.text.__pagevec_free)
+*(.text.inode_init_once)
+*(.text.free_vfsmnt)
+*(.text.__user_walk_fd)
+*(.text.cfq_idle_slice_timer)
+*(.text.sys_mmap)
+*(.text.sys_llseek)
+*(.text.prio_tree_remove)
+*(.text.filp_close)
+*(.text.file_permission)
+*(.text.vma_prio_tree_remove)
+*(.text.tcp_ack)
+*(.text.nameidata_to_filp)
+*(.text.sys_lseek)
+*(.text.percpu_counter_mod)
+*(.text.igrab)
+*(.text.__bread)
+*(.text.alloc_inode)
+*(.text.filldir)
+*(.text.__rb_rotate_left)
+*(.text.irq_affinity_write_proc)
+*(.text.init_request_from_bio)
+*(.text.find_or_create_page)
+*(.text.tty_poll)
+*(.text.tcp_sendmsg)
+*(.text.ide_wait_stat)
+*(.text.free_buffer_head)
+*(.text.flush_signal_handlers)
+*(.text.tcp_v4_rcv)
+*(.text.nr_blockdev_pages)
+*(.text.locks_remove_flock)
+*(.text.__iowrite32_copy)
+*(.text.do_filp_open)
+*(.text.try_to_release_page)
+*(.text.page_add_new_anon_rmap)
+*(.text.kmem_cache_size)
+*(.text.eth_type_trans)
+*(.text.try_to_free_buffers)
+*(.text.schedule_tail)
+*(.text.proc_lookup)
+*(.text.no_llseek)
+*(.text.kfree_skbmem)
+*(.text.do_wait)
+*(.text.do_mpage_readpage)
+*(.text.vfs_stat_fd)
+*(.text.tty_write)
+*(.text.705)
+*(.text.sync_page)
+*(.text.__remove_shared_vm_struct)
+*(.text.__kfree_skb)
+*(.text.sock_poll)
+*(.text.get_request_wait)
+*(.text.do_sigaction)
+*(.text.do_brk)
+*(.text.tcp_event_data_recv)
+*(.text.read_chan)
+*(.text.pipe_writev)
+*(.text.__emul_lookup_dentry)
+*(.text.rtc_get_rtc_time)
+*(.text.print_objinfo)
+*(.text.file_update_time)
+*(.text.do_signal)
+*(.text.disable_8259A_irq)
+*(.text.blk_queue_bounce)
+*(.text.__anon_vma_link)
+*(.text.__vma_link)
+*(.text.vfs_rename)
+*(.text.sys_newlstat)
+*(.text.sys_newfstat)
+*(.text.sys_mknod)
+*(.text.__show_regs)
+*(.text.iput)
+*(.text.get_signal_to_deliver)
+*(.text.flush_tlb_page)
+*(.text.debug_mutex_wake_waiter)
+*(.text.copy_thread)
+*(.text.clear_page_dirty_for_io)
+*(.text.buffer_io_error)
+*(.text.vfs_permission)
+*(.text.truncate_inode_pages_range)
+*(.text.sys_recvfrom)
+*(.text.remove_suid)
+*(.text.mark_buffer_dirty)
+*(.text.local_bh_enable)
+*(.text.get_zeroed_page)
+*(.text.get_vmalloc_info)
+*(.text.flush_old_exec)
+*(.text.dummy_inode_permission)
+*(.text.__bio_add_page)
+*(.text.prio_tree_replace)
+*(.text.notify_change)
+*(.text.mntput_no_expire)
+*(.text.fput)
+*(.text.__end_that_request_first)
+*(.text.wake_up_bit)
+*(.text.unuse_mm)
+*(.text.skb_release_data)
+*(.text.shrink_icache_memory)
+*(.text.sched_balance_self)
+*(.text.__pmd_alloc)
+*(.text.pipe_poll)
+*(.text.normal_poll)
+*(.text.__free_pages)
+*(.text.follow_mount)
+*(.text.cdrom_start_packet_command)
+*(.text.blk_recount_segments)
+*(.text.bio_put)
+*(.text.__alloc_skb)
+*(.text.__wake_up)
+*(.text.vm_stat_account)
+*(.text.sys_fcntl)
+*(.text.sys_fadvise64)
+*(.text._raw_write_unlock)
+*(.text.__pud_alloc)
+*(.text.alloc_page_buffers)
+*(.text.vfs_llseek)
+*(.text.sockfd_lookup)
+*(.text._raw_write_lock)
+*(.text.put_compound_page)
+*(.text.prune_dcache)
+*(.text.pipe_readv)
+*(.text.mempool_free)
+*(.text.make_ahead_window)
+*(.text.lru_add_drain)
+*(.text.constant_test_bit)
+*(.text.__clear_user)
+*(.text.arch_unmap_area)
+*(.text.anon_vma_link)
+*(.text.sys_chroot)
+*(.text.setup_arg_pages)
+*(.text.radix_tree_preload)
+*(.text.init_rwsem)
+*(.text.generic_osync_inode)
+*(.text.generic_delete_inode)
+*(.text.do_sys_poll)
+*(.text.dev_queue_xmit)
+*(.text.default_llseek)
+*(.text.__writeback_single_inode)
+*(.text.vfs_ioctl)
+*(.text.__up_write)
+*(.text.unix_poll)
+*(.text.sys_rt_sigprocmask)
+*(.text.sock_recvmsg)
+*(.text.recalc_bh_state)
+*(.text.__put_unused_fd)
+*(.text.process_backlog)
+*(.text.locks_remove_posix)
+*(.text.lease_modify)
+*(.text.expand_files)
+*(.text.end_buffer_read_nobh)
+*(.text.d_splice_alias)
+*(.text.debug_mutex_init_waiter)
+*(.text.copy_from_user)
+*(.text.cap_vm_enough_memory)
+*(.text.show_vfsmnt)
+*(.text.release_sock)
+*(.text.pfifo_fast_enqueue)
+*(.text.half_md4_transform)
+*(.text.fs_may_remount_ro)
+*(.text.do_fork)
+*(.text.copy_hugetlb_page_range)
+*(.text.cache_free_debugcheck)
+*(.text.__tcp_select_window)
+*(.text.task_handoff_register)
+*(.text.sys_open)
+*(.text.strlcpy)
+*(.text.skb_copy_datagram_iovec)
+*(.text.set_up_list3s)
+*(.text.release_open_intent)
+*(.text.qdisc_restart)
+*(.text.n_tty_chars_in_buffer)
+*(.text.inode_change_ok)
+*(.text.__downgrade_write)
+*(.text.debug_mutex_unlock)
+*(.text.add_timer_randomness)
+*(.text.sock_common_recvmsg)
+*(.text.set_bh_page)
+*(.text.printk_lock)
+*(.text.path_release_on_umount)
+*(.text.ip_output)
+*(.text.ide_build_dmatable)
+*(.text.__get_user_8)
+*(.text.end_buffer_read_sync)
+*(.text.__d_path)
+*(.text.d_move)
+*(.text.del_timer)
+*(.text.constant_test_bit)
+*(.text.blockable_page_cache_readahead)
+*(.text.tty_read)
+*(.text.sys_readlink)
+*(.text.sys_faccessat)
+*(.text.read_swap_cache_async)
+*(.text.pty_write_room)
+*(.text.page_address_in_vma)
+*(.text.kthread)
+*(.text.cfq_exit_io_context)
+*(.text.__tcp_push_pending_frames)
+*(.text.sys_pipe)
+*(.text.submit_bio)
+*(.text.pid_revalidate)
+*(.text.page_referenced_file)
+*(.text.lock_sock)
+*(.text.get_page_state_node)
+*(.text.generic_block_bmap)
+*(.text.do_setitimer)
+*(.text.dev_queue_xmit_nit)
+*(.text.copy_from_read_buf)
+*(.text.__const_udelay)
+*(.text.console_conditional_schedule)
+*(.text.wake_up_new_task)
+*(.text.wait_for_completion_interruptible)
+*(.text.tcp_rcv_rtt_update)
+*(.text.sys_mlockall)
+*(.text.set_fs_altroot)
+*(.text.schedule_timeout)
+*(.text.nr_free_pagecache_pages)
+*(.text.nf_iterate)
+*(.text.mapping_tagged)
+*(.text.ip_queue_xmit)
+*(.text.ip_local_deliver)
+*(.text.follow_page)
+*(.text.elf_map)
+*(.text.dummy_file_permission)
+*(.text.dispose_list)
+*(.text.dentry_open)
+*(.text.dentry_iput)
+*(.text.bio_alloc)
+*(.text.alloc_skb_from_cache)
+*(.text.wait_on_page_bit)
+*(.text.vfs_readdir)
+*(.text.vfs_lstat)
+*(.text.seq_escape)
+*(.text.__posix_lock_file)
+*(.text.mm_release)
+*(.text.kref_put)
+*(.text.ip_rcv)
+*(.text.__iget)
+*(.text.free_pages)
+*(.text.find_mergeable_anon_vma)
+*(.text.find_extend_vma)
+*(.text.dummy_inode_listsecurity)
+*(.text.bio_add_page)
+*(.text.__vm_enough_memory)
+*(.text.vfs_stat)
+*(.text.tty_paranoia_check)
+*(.text.tcp_read_sock)
+*(.text.tcp_data_queue)
+*(.text.sys_uname)
+*(.text.sys_renameat)
+*(.text.__strncpy_from_user)
+*(.text.__mutex_init)
+*(.text.__lookup_hash)
+*(.text.kref_get)
+*(.text.ip_route_input)
+*(.text.__insert_inode_hash)
+*(.text.do_sock_write)
+*(.text.blk_done_softirq)
+*(.text.__wake_up_sync)
+*(.text.__vma_link_rb)
+*(.text.tty_ioctl)
+*(.text.tracesys)
+*(.text.sys_getdents)
+*(.text.sys_dup)
+*(.text.stub_execve)
+*(.text.sha_transform)
+*(.text.radix_tree_tag_clear)
+*(.text.put_unused_fd)
+*(.text.put_files_struct)
+*(.text.mpage_readpages)
+*(.text.may_delete)
+*(.text.kmem_cache_create)
+*(.text.ip_mc_output)
+*(.text.interleave_nodes)
+*(.text.groups_search)
+*(.text.generic_drop_inode)
+*(.text.generic_commit_write)
+*(.text.fcntl_setlk)
+*(.text.exit_mmap)
+*(.text.end_page_writeback)
+*(.text.__d_rehash)
+*(.text.debug_mutex_free_waiter)
+*(.text.csum_ipv6_magic)
+*(.text.count)
+*(.text.cleanup_rbuf)
+*(.text.check_spinlock_acquired_node)
+*(.text.can_vma_merge_after)
+*(.text.bio_endio)
+*(.text.alloc_pidmap)
+*(.text.write_ldt)
+*(.text.vmtruncate_range)
+*(.text.vfs_create)
+*(.text.__user_walk)
+*(.text.update_send_head)
+*(.text.unmap_underlying_metadata)
+*(.text.tty_ldisc_deref)
+*(.text.tcp_setsockopt)
+*(.text.tcp_send_ack)
+*(.text.sys_pause)
+*(.text.sys_gettimeofday)
+*(.text.sync_dirty_buffer)
+*(.text.strncmp)
+*(.text.release_posix_timer)
+*(.text.proc_file_read)
+*(.text.prepare_to_wait)
+*(.text.locks_mandatory_locked)
+*(.text.interruptible_sleep_on_timeout)
+*(.text.inode_sub_bytes)
+*(.text.in_group_p)
+*(.text.hrtimer_try_to_cancel)
+*(.text.filldir64)
+*(.text.fasync_helper)
+*(.text.dummy_sb_pivotroot)
+*(.text.d_lookup)
+*(.text.d_instantiate)
+*(.text.__d_find_alias)
+*(.text.cpu_idle_wait)
+*(.text.cond_resched_lock)
+*(.text.chown_common)
+*(.text.blk_congestion_wait)
+*(.text.activate_page)
+*(.text.unlock_buffer)
+*(.text.tty_wakeup)
+*(.text.tcp_v4_do_rcv)
+*(.text.tcp_current_mss)
+*(.text.sys_openat)
+*(.text.sys_fchdir)
+*(.text.strnlen_user)
+*(.text.strnlen)
+*(.text.strchr)
+*(.text.sock_common_getsockopt)
+*(.text.skb_checksum)
+*(.text.remove_wait_queue)
+*(.text.rb_replace_node)
+*(.text.radix_tree_node_ctor)
+*(.text.pty_chars_in_buffer)
+*(.text.profile_hit)
+*(.text.prio_tree_left)
+*(.text.pgd_clear_bad)
+*(.text.pfifo_fast_dequeue)
+*(.text.page_referenced)
+*(.text.open_exec)
+*(.text.mmput)
+*(.text.mm_init)
+*(.text.__ide_dma_off_quietly)
+*(.text.ide_dma_intr)
+*(.text.hrtimer_start)
+*(.text.get_io_context)
+*(.text.__get_free_pages)
+*(.text.find_first_zero_bit)
+*(.text.file_free_rcu)
+*(.text.dummy_socket_sendmsg)
+*(.text.do_unlinkat)
+*(.text.do_arch_prctl)
+*(.text.destroy_inode)
+*(.text.can_vma_merge_before)
+*(.text.block_sync_page)
+*(.text.block_prepare_write)
+*(.text.bio_init)
+*(.text.arch_ptrace)
+*(.text.wake_up_inode)
+*(.text.wait_on_retry_sync_kiocb)
+*(.text.vma_prio_tree_next)
+*(.text.tcp_rcv_space_adjust)
+*(.text.__tcp_ack_snd_check)
+*(.text.sys_utime)
+*(.text.sys_recvmsg)
+*(.text.sys_mremap)
+*(.text.sys_bdflush)
+*(.text.sleep_on)
+*(.text.set_page_dirty_lock)
+*(.text.seq_path)
+*(.text.schedule_timeout_interruptible)
+*(.text.sched_fork)
+*(.text.rt_run_flush)
+*(.text.profile_munmap)
+*(.text.prepare_binprm)
+*(.text.__pagevec_release_nonlru)
+*(.text.m_show)
+*(.text.lookup_mnt)
+*(.text.__lookup_mnt)
+*(.text.lock_timer_base)
+*(.text.is_subdir)
+*(.text.invalidate_bh_lru)
+*(.text.init_buffer_head)
+*(.text.ifind_fast)
+*(.text.ide_dma_start)
+*(.text.__get_page_state)
+*(.text.flock_to_posix_lock)
+*(.text.__find_symbol)
+*(.text.do_futex)
+*(.text.do_execve)
+*(.text.dirty_writeback_centisecs_handler)
+*(.text.dev_watchdog)
+*(.text.can_share_swap_page)
+*(.text.blkdev_put)
+*(.text.bio_get_nr_vecs)
+*(.text.xfrm_compile_policy)
+*(.text.vma_prio_tree_insert)
+*(.text.vfs_lstat_fd)
+*(.text.__user_path_lookup_open)
+*(.text.thread_return)
+*(.text.tcp_send_delayed_ack)
+*(.text.sock_def_error_report)
+*(.text.shrink_slab)
+*(.text.serial_out)
+*(.text.seq_read)
+*(.text.secure_ip_id)
+*(.text.search_binary_handler)
+*(.text.proc_pid_unhash)
+*(.text.pagevec_lookup)
+*(.text.new_inode)
+*(.text.memcpy_toiovec)
+*(.text.locks_free_lock)
+*(.text.__lock_page)
+*(.text.__lock_buffer)
+*(.text.load_module)
+*(.text.is_bad_inode)
+*(.text.invalidate_inode_buffers)
+*(.text.insert_vm_struct)
+*(.text.inode_setattr)
+*(.text.inode_add_bytes)
+*(.text.ide_read_24)
+*(.text.ide_get_error_location)
+*(.text.ide_do_drive_cmd)
+*(.text.get_locked_pte)
+*(.text.get_filesystem_list)
+*(.text.generic_file_open)
+*(.text.follow_down)
+*(.text.find_next_bit)
+*(.text.__find_first_bit)
+*(.text.exit_mm)
+*(.text.exec_keys)
+*(.text.end_buffer_write_sync)
+*(.text.end_bio_bh_io_sync)
+*(.text.dummy_socket_shutdown)
+*(.text.d_rehash)
+*(.text.d_path)
+*(.text.do_ioctl)
+*(.text.dget_locked)
+*(.text.copy_thread_group_keys)
+*(.text.cdrom_end_request)
+*(.text.cap_bprm_apply_creds)
+*(.text.blk_rq_bio_prep)
+*(.text.__bitmap_intersects)
+*(.text.bio_phys_segments)
+*(.text.bio_free)
+*(.text.arch_get_unmapped_area_topdown)
+*(.text.writeback_in_progress)
+*(.text.vfs_follow_link)
+*(.text.tcp_rcv_state_process)
+*(.text.tcp_check_space)
+*(.text.sys_stat)
+*(.text.sys_rt_sigreturn)
+*(.text.sys_rt_sigaction)
+*(.text.sys_remap_file_pages)
+*(.text.sys_pwrite64)
+*(.text.sys_fchownat)
+*(.text.sys_fchmodat)
+*(.text.strncat)
+*(.text.strlcat)
+*(.text.strcmp)
+*(.text.steal_locks)
+*(.text.sock_create)
+*(.text.sk_stream_rfree)
+*(.text.sk_stream_mem_schedule)
+*(.text.skip_atoi)
+*(.text.sk_alloc)
+*(.text.show_stat)
+*(.text.set_fs_pwd)
+*(.text.set_binfmt)
+*(.text.pty_unthrottle)
+*(.text.proc_symlink)
+*(.text.pipe_release)
+*(.text.pageout)
+*(.text.n_tty_write_wakeup)
+*(.text.n_tty_ioctl)
+*(.text.nr_free_zone_pages)
+*(.text.migration_thread)
+*(.text.mempool_free_slab)
+*(.text.meminfo_read_proc)
+*(.text.max_sane_readahead)
+*(.text.lru_cache_add)
+*(.text.kill_fasync)
+*(.text.kernel_read)
+*(.text.invalidate_mapping_pages)
+*(.text.inode_has_buffers)
+*(.text.init_once)
+*(.text.inet_sendmsg)
+*(.text.idedisk_issue_flush)
+*(.text.generic_file_write)
+*(.text.free_more_memory)
+*(.text.__free_fdtable)
+*(.text.filp_dtor)
+*(.text.exit_sem)
+*(.text.exit_itimers)
+*(.text.error_interrupt)
+*(.text.end_buffer_async_write)
+*(.text.eligible_child)
+*(.text.elf_map)
+*(.text.dump_task_regs)
+*(.text.dummy_task_setscheduler)
+*(.text.dummy_socket_accept)
+*(.text.dummy_file_free_security)
+*(.text.__down_read)
+*(.text.do_sock_read)
+*(.text.do_sigaltstack)
+*(.text.do_mremap)
+*(.text.current_io_context)
+*(.text.cpu_swap_callback)
+*(.text.copy_vma)
+*(.text.cap_bprm_set_security)
+*(.text.blk_insert_request)
+*(.text.bio_map_kern_endio)
+*(.text.bio_hw_segments)
+*(.text.bictcp_cong_avoid)
+*(.text.add_interrupt_randomness)
+*(.text.wait_for_completion)
+*(.text.version_read_proc)
+*(.text.unix_write_space)
+*(.text.tty_ldisc_ref_wait)
+*(.text.tty_ldisc_put)
+*(.text.try_to_wake_up)
+*(.text.tcp_v4_tw_remember_stamp)
+*(.text.tcp_try_undo_dsack)
+*(.text.tcp_may_send_now)
+*(.text.sys_waitid)
+*(.text.sys_sched_getparam)
+*(.text.sys_getppid)
+*(.text.sys_getcwd)
+*(.text.sys_dup2)
+*(.text.sys_chmod)
+*(.text.sys_chdir)
+*(.text.sprintf)
+*(.text.sock_wfree)
+*(.text.sock_aio_write)
+*(.text.skb_drop_fraglist)
+*(.text.skb_dequeue)
+*(.text.set_close_on_exec)
+*(.text.set_brk)
+*(.text.seq_puts)
+*(.text.SELECT_DRIVE)
+*(.text.sched_exec)
+*(.text.return_EIO)
+*(.text.remove_from_page_cache)
+*(.text.rcu_start_batch)
+*(.text.__put_task_struct)
+*(.text.proc_pid_readdir)
+*(.text.proc_get_inode)
+*(.text.prepare_to_wait_exclusive)
+*(.text.pipe_wait)
+*(.text.pipe_new)
+*(.text.pdflush_operation)
+*(.text.__pagevec_release)
+*(.text.pagevec_lookup_tag)
+*(.text.packet_rcv)
+*(.text.n_tty_set_room)
+*(.text.nr_free_pages)
+*(.text.__net_timestamp)
+*(.text.mpage_end_io_read)
+*(.text.mod_timer)
+*(.text.__memcpy)
+*(.text.mb_cache_shrink_fn)
+*(.text.lock_rename)
+*(.text.kstrdup)
+*(.text.is_ignored)
+*(.text.int_very_careful)
+*(.text.inotify_inode_is_dead)
+*(.text.inotify_get_cookie)
+*(.text.inode_get_bytes)
+*(.text.init_timer)
+*(.text.init_dev)
+*(.text.inet_getname)
+*(.text.ide_map_sg)
+*(.text.__ide_dma_end)
+*(.text.hrtimer_get_remaining)
+*(.text.get_task_mm)
+*(.text.get_random_int)
+*(.text.free_pipe_info)
+*(.text.filemap_write_and_wait_range)
+*(.text.exit_thread)
+*(.text.enter_idle)
+*(.text.end_that_request_first)
+*(.text.end_8259A_irq)
+*(.text.dummy_file_alloc_security)
+*(.text.do_group_exit)
+*(.text.debug_mutex_init)
+*(.text.cpuset_exit)
+*(.text.cpu_idle)
+*(.text.copy_semundo)
+*(.text.copy_files)
+*(.text.chrdev_open)
+*(.text.cdrom_transfer_packet_command)
+*(.text.cdrom_mode_sense)
+*(.text.blk_phys_contig_segment)
+*(.text.blk_get_queue)
+*(.text.bio_split)
+*(.text.audit_alloc)
+*(.text.anon_pipe_buf_release)
+*(.text.add_wait_queue_exclusive)
+*(.text.add_wait_queue)
+*(.text.acct_process)
+*(.text.account)
+*(.text.zeromap_page_range)
+*(.text.yield)
+*(.text.writeback_acquire)
+*(.text.worker_thread)
+*(.text.wait_on_page_writeback_range)
+*(.text.__wait_on_buffer)
+*(.text.vscnprintf)
+*(.text.vmalloc_to_pfn)
+*(.text.vgacon_save_screen)
+*(.text.vfs_unlink)
+*(.text.vfs_rmdir)
+*(.text.unregister_md_personality)
+*(.text.unlock_new_inode)
+*(.text.unix_stream_sendmsg)
+*(.text.unix_stream_recvmsg)
+*(.text.unhash_process)
+*(.text.udp_v4_lookup_longway)
+*(.text.tty_ldisc_flush)
+*(.text.tty_ldisc_enable)
+*(.text.tty_hung_up_p)
+*(.text.tty_buffer_free_all)
+*(.text.tso_fragment)
+*(.text.try_to_del_timer_sync)
+*(.text.tcp_v4_err)
+*(.text.tcp_unhash)
+*(.text.tcp_seq_next)
+*(.text.tcp_select_initial_window)
+*(.text.tcp_sacktag_write_queue)
+*(.text.tcp_cwnd_validate)
+*(.text.sys_vhangup)
+*(.text.sys_uselib)
+*(.text.sys_symlink)
+*(.text.sys_signal)
+*(.text.sys_poll)
+*(.text.sys_mount)
+*(.text.sys_kill)
+*(.text.sys_ioctl)
+*(.text.sys_inotify_add_watch)
+*(.text.sys_getuid)
+*(.text.sys_getrlimit)
+*(.text.sys_getitimer)
+*(.text.sys_getgroups)
+*(.text.sys_ftruncate)
+*(.text.sysfs_lookup)
+*(.text.sys_exit_group)
+*(.text.stub_fork)
+*(.text.sscanf)
+*(.text.sock_map_fd)
+*(.text.sock_get_timestamp)
+*(.text.__sock_create)
+*(.text.smp_call_function_single)
+*(.text.sk_stop_timer)
+*(.text.skb_copy_and_csum_datagram)
+*(.text.__skb_checksum_complete)
+*(.text.single_next)
+*(.text.sigqueue_alloc)
+*(.text.shrink_dcache_parent)
+*(.text.select_idle_routine)
+*(.text.run_workqueue)
+*(.text.run_local_timers)
+*(.text.remove_inode_hash)
+*(.text.remove_dquot_ref)
+*(.text.register_binfmt)
+*(.text.read_cache_pages)
+*(.text.rb_last)
+*(.text.pty_open)
+*(.text.proc_root_readdir)
+*(.text.proc_pid_flush)
+*(.text.proc_pident_lookup)
+*(.text.proc_fill_super)
+*(.text.proc_exe_link)
+*(.text.posix_locks_deadlock)
+*(.text.pipe_iov_copy_from_user)
+*(.text.opost)
+*(.text.nf_register_hook)
+*(.text.netif_rx_ni)
+*(.text.m_start)
+*(.text.mpage_writepage)
+*(.text.mm_alloc)
+*(.text.memory_open)
+*(.text.mark_buffer_async_write)
+*(.text.lru_add_drain_all)
+*(.text.locks_init_lock)
+*(.text.locks_delete_lock)
+*(.text.lock_hrtimer_base)
+*(.text.load_script)
+*(.text.__kill_fasync)
+*(.text.ip_mc_sf_allow)
+*(.text.__ioremap)
+*(.text.int_with_check)
+*(.text.int_sqrt)
+*(.text.install_thread_keyring)
+*(.text.init_page_buffers)
+*(.text.inet_sock_destruct)
+*(.text.idle_notifier_register)
+*(.text.ide_execute_command)
+*(.text.ide_end_drive_cmd)
+*(.text.__ide_dma_host_on)
+*(.text.hrtimer_run_queues)
+*(.text.hpet_mask_rtc_irq_bit)
+*(.text.__get_zone_counts)
+*(.text.get_zone_counts)
+*(.text.get_write_access)
+*(.text.get_fs_struct)
+*(.text.get_dirty_limits)
+*(.text.generic_readlink)
+*(.text.free_hot_page)
+*(.text.finish_wait)
+*(.text.find_inode)
+*(.text.find_first_bit)
+*(.text.__filemap_fdatawrite_range)
+*(.text.__filemap_copy_from_user_iovec)
+*(.text.exit_aio)
+*(.text.elv_set_request)
+*(.text.elv_former_request)
+*(.text.dup_namespace)
+*(.text.dupfd)
+*(.text.dummy_socket_getsockopt)
+*(.text.dummy_sb_post_mountroot)
+*(.text.dummy_quotactl)
+*(.text.dummy_inode_rename)
+*(.text.__do_SAK)
+*(.text.do_pipe)
+*(.text.do_fsync)
+*(.text.d_instantiate_unique)
+*(.text.d_find_alias)
+*(.text.deny_write_access)
+*(.text.dentry_unhash)
+*(.text.d_delete)
+*(.text.datagram_poll)
+*(.text.cpuset_fork)
+*(.text.cpuid_read)
+*(.text.copy_namespace)
+*(.text.cond_resched)
+*(.text.check_version)
+*(.text.__change_page_attr)
+*(.text.cfq_slab_kill)
+*(.text.cfq_completed_request)
+*(.text.cdrom_pc_intr)
+*(.text.cdrom_decode_status)
+*(.text.cap_capset_check)
+*(.text.blk_put_request)
+*(.text.bio_fs_destructor)
+*(.text.bictcp_min_cwnd)
+*(.text.alloc_chrdev_region)
+*(.text.add_element)
+*(.text.acct_update_integrals)
+*(.text.write_boundary_block)
+*(.text.writeback_release)
+*(.text.writeback_inodes)
+*(.text.wake_up_state)
+*(.text.__wake_up_locked)
+*(.text.wake_futex)
+*(.text.wait_task_inactive)
+*(.text.__wait_on_freeing_inode)
+*(.text.wait_noreap_copyout)
+*(.text.vmstat_start)
+*(.text.vgacon_do_font_op)
+*(.text.vfs_readv)
+*(.text.vfs_quota_sync)
+*(.text.update_queue)
+*(.text.unshare_files)
+*(.text.unmap_vm_area)
+*(.text.unix_socketpair)
+*(.text.unix_release_sock)
+*(.text.unix_detach_fds)
+*(.text.unix_create1)
+*(.text.unix_bind)
+*(.text.udp_sendmsg)
+*(.text.udp_rcv)
+*(.text.udp_queue_rcv_skb)
+*(.text.uart_write)
+*(.text.uart_startup)
+*(.text.uart_open)
+*(.text.tty_vhangup)
+*(.text.tty_termios_baud_rate)
+*(.text.tty_release)
+*(.text.tty_ldisc_ref)
+*(.text.throttle_vm_writeout)
+*(.text.058)
+*(.text.tcp_xmit_probe_skb)
+*(.text.tcp_v4_send_check)
+*(.text.tcp_v4_destroy_sock)
+*(.text.tcp_sync_mss)
+*(.text.tcp_snd_test)
+*(.text.tcp_slow_start)
+*(.text.tcp_send_fin)
+*(.text.tcp_rtt_estimator)
+*(.text.tcp_parse_options)
+*(.text.tcp_ioctl)
+*(.text.tcp_init_tso_segs)
+*(.text.tcp_init_cwnd)
+*(.text.tcp_getsockopt)
+*(.text.tcp_fin)
+*(.text.tcp_connect)
+*(.text.tcp_cong_avoid)
+*(.text.__tcp_checksum_complete_user)
+*(.text.task_dumpable)
+*(.text.sys_wait4)
+*(.text.sys_utimes)
+*(.text.sys_symlinkat)
+*(.text.sys_socketpair)
+*(.text.sys_rmdir)
+*(.text.sys_readahead)
+*(.text.sys_nanosleep)
+*(.text.sys_linkat)
+*(.text.sys_fstat)
+*(.text.sysfs_readdir)
+*(.text.sys_execve)
+*(.text.sysenter_tracesys)
+*(.text.sys_chown)
+*(.text.stub_clone)
+*(.text.strrchr)
+*(.text.strncpy)
+*(.text.stopmachine_set_state)
+*(.text.sock_sendmsg)
+*(.text.sock_release)
+*(.text.sock_fasync)
+*(.text.sock_close)
+*(.text.sk_stream_write_space)
+*(.text.sk_reset_timer)
+*(.text.skb_split)
+*(.text.skb_recv_datagram)
+*(.text.skb_queue_tail)
+*(.text.sk_attach_filter)
+*(.text.si_swapinfo)
+*(.text.simple_strtoll)
+*(.text.set_termios)
+*(.text.set_task_comm)
+*(.text.set_shrinker)
+*(.text.set_normalized_timespec)
+*(.text.set_brk)
+*(.text.serial_in)
+*(.text.seq_printf)
+*(.text.secure_dccp_sequence_number)
+*(.text.rwlock_bug)
+*(.text.rt_hash_code)
+*(.text.__rta_fill)
+*(.text.__request_resource)
+*(.text.relocate_new_kernel)
+*(.text.release_thread)
+*(.text.release_mem)
+*(.text.rb_prev)
+*(.text.rb_first)
+*(.text.random_poll)
+*(.text.__put_super_and_need_restart)
+*(.text.pty_write)
+*(.text.ptrace_stop)
+*(.text.proc_self_readlink)
+*(.text.proc_root_lookup)
+*(.text.proc_root_link)
+*(.text.proc_pid_make_inode)
+*(.text.proc_pid_attr_write)
+*(.text.proc_lookupfd)
+*(.text.proc_delete_inode)
+*(.text.posix_same_owner)
+*(.text.posix_block_lock)
+*(.text.poll_initwait)
+*(.text.pipe_write)
+*(.text.pipe_read_fasync)
+*(.text.pipe_ioctl)
+*(.text.pdflush)
+*(.text.pci_user_read_config_dword)
+*(.text.page_readlink)
+*(.text.null_lseek)
+*(.text.nf_hook_slow)
+*(.text.netlink_sock_destruct)
+*(.text.netlink_broadcast)
+*(.text.neigh_resolve_output)
+*(.text.name_to_int)
+*(.text.mwait_idle)
+*(.text.mutex_trylock)
+*(.text.mutex_debug_check_no_locks_held)
+*(.text.m_stop)
+*(.text.mpage_end_io_write)
+*(.text.mpage_alloc)
+*(.text.move_page_tables)
+*(.text.mounts_open)
+*(.text.__memset)
+*(.text.memcpy_fromiovec)
+*(.text.make_8259A_irq)
+*(.text.lookup_user_key_possessed)
+*(.text.lookup_create)
+*(.text.locks_insert_lock)
+*(.text.locks_alloc_lock)
+*(.text.kthread_should_stop)
+*(.text.kswapd)
+*(.text.kobject_uevent)
+*(.text.kobject_get_path)
+*(.text.kobject_get)
+*(.text.klist_children_put)
+*(.text.__ip_route_output_key)
+*(.text.ip_flush_pending_frames)
+*(.text.ip_compute_csum)
+*(.text.ip_append_data)
+*(.text.ioc_set_batching)
+*(.text.invalidate_inode_pages)
+*(.text.__invalidate_device)
+*(.text.install_arg_page)
+*(.text.in_sched_functions)
+*(.text.inotify_unmount_inodes)
+*(.text.init_once)
+*(.text.init_cdrom_command)
+*(.text.inet_stream_connect)
+*(.text.inet_sk_rebuild_header)
+*(.text.inet_csk_addr2sockaddr)
+*(.text.inet_create)
+*(.text.ifind)
+*(.text.ide_setup_dma)
+*(.text.ide_outsw)
+*(.text.ide_fixstring)
+*(.text.ide_dma_setup)
+*(.text.ide_cdrom_packet)
+*(.text.ide_cd_put)
+*(.text.ide_build_sglist)
+*(.text.i8259A_shutdown)
+*(.text.hung_up_tty_ioctl)
+*(.text.hrtimer_nanosleep)
+*(.text.hrtimer_init)
+*(.text.hrtimer_cancel)
+*(.text.hash_futex)
+*(.text.group_send_sig_info)
+*(.text.grab_cache_page_nowait)
+*(.text.get_wchan)
+*(.text.get_stack)
+*(.text.get_page_state)
+*(.text.getnstimeofday)
+*(.text.get_node)
+*(.text.get_kprobe)
+*(.text.generic_unplug_device)
+*(.text.free_task)
+*(.text.frag_show)
+*(.text.find_next_zero_string)
+*(.text.filp_open)
+*(.text.fillonedir)
+*(.text.exit_io_context)
+*(.text.exit_idle)
+*(.text.exact_lock)
+*(.text.eth_header)
+*(.text.dummy_unregister_security)
+*(.text.dummy_socket_post_create)
+*(.text.dummy_socket_listen)
+*(.text.dummy_quota_on)
+*(.text.dummy_inode_follow_link)
+*(.text.dummy_file_receive)
+*(.text.dummy_file_mprotect)
+*(.text.dummy_file_lock)
+*(.text.dummy_file_ioctl)
+*(.text.dummy_bprm_post_apply_creds)
+*(.text.do_writepages)
+*(.text.__down_interruptible)
+*(.text.do_notify_resume)
+*(.text.do_acct_process)
+*(.text.del_timer_sync)
+*(.text.default_rebuild_header)
+*(.text.d_callback)
+*(.text.dcache_readdir)
+*(.text.ctrl_dumpfamily)
+*(.text.cpuset_rmdir)
+*(.text.copy_strings_kernel)
+*(.text.con_write_room)
+*(.text.complete_all)
+*(.text.collect_sigign_sigcatch)
+*(.text.clear_user)
+*(.text.check_unthrottle)
+*(.text.cdrom_release)
+*(.text.cdrom_newpc_intr)
+*(.text.cdrom_ioctl)
+*(.text.cdrom_check_status)
+*(.text.cdev_put)
+*(.text.cdev_add)
+*(.text.cap_ptrace)
+*(.text.cap_bprm_secureexec)
+*(.text.cache_alloc_refill)
+*(.text.bmap)
+*(.text.blk_run_queue)
+*(.text.blk_queue_dma_alignment)
+*(.text.blk_ordered_req_seq)
+*(.text.blk_backing_dev_unplug)
+*(.text.__bitmap_subset)
+*(.text.__bitmap_and)
+*(.text.bio_unmap_user)
+*(.text.__bforget)
+*(.text.bd_forget)
+*(.text.bad_pipe_w)
+*(.text.bad_get_user)
+*(.text.audit_free)
+*(.text.anon_vma_ctor)
+*(.text.anon_pipe_buf_map)
+*(.text.alloc_sock_iocb)
+*(.text.alloc_fdset)
+*(.text.aio_kick_handler)
+*(.text.__add_entropy_words)
+*(.text.add_disk_randomness)
Index: linux-2.6.16-reorder/scripts/profile2linkerlist.pl
===================================================================
--- /dev/null
+++ linux-2.6.16-reorder/scripts/profile2linkerlist.pl
@@ -0,0 +1,21 @@
+#!/usr/bin/perl
+
+#
+# Takes a (sorted) output of readprofile and turns it into a list suitable for
+# linker scripts
+#
+# usage:
+# readprofile | sort -rn | perl profile2linkerlist.pl > functionlist
+#
+
+while (<>) {
+ my $line = $_;
+
+ $_ =~ /\W*[0-9]+\W*([a-zA-Z\_0-9]+)\W*[0-9]+/;
+
+ if ( ($line =~ /unknown/) || ($line =~ /total/)) {
+
+ } else {
+ print "*(.text.$1)\n";
+ }
+}

2006-02-23 16:00:43

by Andi Kleen

[permalink] [raw]
Subject: Re: Patch to reorder functions in the vmlinux to a defined order

On Thursday 23 February 2006 16:09, Arjan van de Ven wrote:

> This patch puts the infrastructure in place to allow for a reordering of
> functions based inside the vmlinux. The general idea is that it is possible
> to put all "common" functions into the first 2Mb of the code, so that they
> are covered by one TLB entry. This as opposed to the current situation where
> a typical vmlinux covers about 3.5Mb (on x86-64) and thus 2 TLB entries.
> (This patch depends on the previous patch to pin head.S as first in the order)

I think you would first need to move the code first for that. Currently it starts
at 1MB, which means 1MB is already wasted of the aligned 2MB TLB entry.

I wouldn't have a problem with moving the 64bit kernel to 2MB though.

>
> I think that to get to a better list we need to invite people to submit
> their own profiles, and somehow add those all up and base the final list on
> that. I'm willing to do that effort if this is ends up being the prefered
> approach. Such an effort probably needs to be repeated like once a year or
> so to adopt to the changing nature of the kernel.

Looks reasonable.

Afaik newer gcc can even separate likely and unlikely code into different sections.
I don't see you trying to handle that.

Also if you're serious about saving TLBs it might be worth it to prereserve
some memory near the main kernel mapping for modules (e.g. with a boot option)
and load them there. Then they would be covered with the same TLB entry too.

-Andi

2006-02-23 16:03:11

by Arjan van de Ven

[permalink] [raw]
Subject: Re: Patch to reorder functions in the vmlinux to a defined order

Andi Kleen wrote:
> On Thursday 23 February 2006 16:09, Arjan van de Ven wrote:
>
>> This patch puts the infrastructure in place to allow for a reordering of
>> functions based inside the vmlinux. The general idea is that it is possible
>> to put all "common" functions into the first 2Mb of the code, so that they
>> are covered by one TLB entry. This as opposed to the current situation where
>> a typical vmlinux covers about 3.5Mb (on x86-64) and thus 2 TLB entries.
>> (This patch depends on the previous patch to pin head.S as first in the order)
>
> I think you would first need to move the code first for that. Currently it starts
> at 1MB, which means 1MB is already wasted of the aligned 2MB TLB entry.
>
> I wouldn't have a problem with moving the 64bit kernel to 2MB though.

ok I am hoping that 1Mb would be enough already but I'll investigate
this, it sure makes sense
>
>> I think that to get to a better list we need to invite people to submit
>> their own profiles, and somehow add those all up and base the final list on
>> that. I'm willing to do that effort if this is ends up being the prefered
>> approach. Such an effort probably needs to be repeated like once a year or
>> so to adopt to the changing nature of the kernel.
>
> Looks reasonable.
>
> Afaik newer gcc can even separate likely and unlikely code into different sections.
> I don't see you trying to handle that.

last discussion about this was that it made code actually bigger because
it now needs long rather than local jumps etc, so the gcc people aren't
too fond of it.

>
> Also if you're serious about saving TLBs it might be worth it to prereserve
> some memory near the main kernel mapping for modules (e.g. with a boot option)
> and load them there. Then they would be covered with the same TLB entry too.

that's on my to-look-at list already yes

2006-02-23 16:43:34

by Arjan van de Ven

[permalink] [raw]
Subject: Re: Patch to reorder functions in the vmlinux to a defined order

On Thu, 2006-02-23 at 17:00 +0100, Andi Kleen wrote:
> On Thursday 23 February 2006 16:09, Arjan van de Ven wrote:
>
> > This patch puts the infrastructure in place to allow for a reordering of
> > functions based inside the vmlinux. The general idea is that it is possible
> > to put all "common" functions into the first 2Mb of the code, so that they
> > are covered by one TLB entry. This as opposed to the current situation where
> > a typical vmlinux covers about 3.5Mb (on x86-64) and thus 2 TLB entries.
> > (This patch depends on the previous patch to pin head.S as first in the order)
>
> I think you would first need to move the code first for that. Currently it starts
> at 1MB, which means 1MB is already wasted of the aligned 2MB TLB entry.
>
> I wouldn't have a problem with moving the 64bit kernel to 2MB though.

that was easy since it's a Config entry already ;)


---


As suggested by Andi (and Alan), move the default kernel location
from 1Mb to 2Mb, to align to the start of a TLB entry.

Signed-off-by: Arjan van de Ven <[email protected]>

---
arch/x86_64/Kconfig | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)

Index: linux-2.6.16-reorder/arch/x86_64/Kconfig
===================================================================
--- linux-2.6.16-reorder.orig/arch/x86_64/Kconfig
+++ linux-2.6.16-reorder/arch/x86_64/Kconfig
@@ -444,10 +444,10 @@ config CRASH_DUMP
config PHYSICAL_START
hex "Physical address where the kernel is loaded" if (EMBEDDED || CRASH_DUMP)
default "0x1000000" if CRASH_DUMP
- default "0x100000"
+ default "0x200000"
help
This gives the physical address where the kernel is loaded. Normally
- for regular kernels this value is 0x100000 (1MB). But in the case
+ for regular kernels this value is 0x200000 (2MB). But in the case
of kexec on panic the fail safe kernel needs to run at a different
address than the panic-ed kernel. This option is used to set the load
address for kernels used to capture crash dump on being kexec'ed

2006-02-23 16:49:01

by Linus Torvalds

[permalink] [raw]
Subject: Re: Patch to reorder functions in the vmlinux to a defined order



On Thu, 23 Feb 2006, Arjan van de Ven wrote:
>
> I think that to get to a better list we need to invite people to submit
> their own profiles, and somehow add those all up and base the final list on
> that. I'm willing to do that effort if this is ends up being the prefered
> approach. Such an effort probably needs to be repeated like once a year or
> so to adopt to the changing nature of the kernel.

I suspect we need architecture-specific profiles.

For example, on x86(-64), memcpy() is mostly inlined for the interesting
cases. That's not always so. Other architectures will have things like the
page copying and clearing as _the_ hottest functions. Same goes for
architecture-specific things like context switching etc, that have
different names on different architectures.

So putting the profile data in scripts/ doesn't sound very good.

That said, this certainly seems simple enough. I'd like to hear about
actual performance improvements with it before I'd apply anything like
this.

Also, since it's quite possible that being dense in the I$ is more of an
issue than being dense in the TLB (especially since almost everybody has
super-pages for kernel TLB entries and thus uses just a single entry - or
maybe a couple - for the kernel), it would probably make sense to try to
take calling patterns into account some way.

That's true of TLB usage too (in the absense of super-pages), of course.

But numbers talk.

Linus

2006-02-23 16:48:59

by Andi Kleen

[permalink] [raw]
Subject: Re: Patch to reorder functions in the vmlinux to a defined order

On Thursday 23 February 2006 17:43, Arjan van de Ven wrote:
> On Thu, 2006-02-23 at 17:00 +0100, Andi Kleen wrote:
> > On Thursday 23 February 2006 16:09, Arjan van de Ven wrote:
> >
> > > This patch puts the infrastructure in place to allow for a reordering of
> > > functions based inside the vmlinux. The general idea is that it is possible
> > > to put all "common" functions into the first 2Mb of the code, so that they
> > > are covered by one TLB entry. This as opposed to the current situation where
> > > a typical vmlinux covers about 3.5Mb (on x86-64) and thus 2 TLB entries.
> > > (This patch depends on the previous patch to pin head.S as first in the order)
> >
> > I think you would first need to move the code first for that. Currently it starts
> > at 1MB, which means 1MB is already wasted of the aligned 2MB TLB entry.
> >
> > I wouldn't have a problem with moving the 64bit kernel to 2MB though.
>
> that was easy since it's a Config entry already ;)


I assume you boot tested it?

-Andi

2006-02-23 16:50:05

by Arjan van de Ven

[permalink] [raw]
Subject: Re: Patch to reorder functions in the vmlinux to a defined order

Andi Kleen wrote:
> On Thursday 23 February 2006 17:43, Arjan van de Ven wrote:
>> On Thu, 2006-02-23 at 17:00 +0100, Andi Kleen wrote:
>>> On Thursday 23 February 2006 16:09, Arjan van de Ven wrote:
>>>
>>>> This patch puts the infrastructure in place to allow for a reordering of
>>>> functions based inside the vmlinux. The general idea is that it is possible
>>>> to put all "common" functions into the first 2Mb of the code, so that they
>>>> are covered by one TLB entry. This as opposed to the current situation where
>>>> a typical vmlinux covers about 3.5Mb (on x86-64) and thus 2 TLB entries.
>>>> (This patch depends on the previous patch to pin head.S as first in the order)
>>> I think you would first need to move the code first for that. Currently it starts
>>> at 1MB, which means 1MB is already wasted of the aligned 2MB TLB entry.
>>>
>>> I wouldn't have a problem with moving the 64bit kernel to 2MB though.
>> that was easy since it's a Config entry already ;)
>
>
> I assume you boot tested it?

yes it booted on my testbox, and system.map showed the 2 instead of the 1

2006-02-23 16:58:06

by linux-os (Dick Johnson)

[permalink] [raw]
Subject: Re: Patch to reorder functions in the vmlinux to a defined order


On Thu, 23 Feb 2006, Arjan van de Ven wrote:

> This patch puts the infrastructure in place to allow for a reordering of
> functions based inside the vmlinux. The general idea is that it is possible
> to put all "common" functions into the first 2Mb of the code, so that they
> are covered by one TLB entry. This as opposed to the current situation where
> a typical vmlinux covers about 3.5Mb (on x86-64) and thus 2 TLB entries.
> (This patch depends on the previous patch to pin head.S as first in the order)
>
> This is done by enabling the -ffunction-sections flag in gcc, which puts
> each function in its own ELF section, so that the linker can then order them
> in a way defined by the linker script.
>
> As per previous discussions, Linus said he wanted a "static" list for this,
> eg a list provided by the kernel tarbal, so that most people have the same
> ordering at least. A script is provided to create this list based on
> readprofile(1) output. The included list is provisional, and entirely biased
> on my own testbox and me running a few kernel compiles and some other
> things.
>
> I think that to get to a better list we need to invite people to submit
> their own profiles, and somehow add those all up and base the final list on
> that. I'm willing to do that effort if this is ends up being the prefered
> approach. Such an effort probably needs to be repeated like once a year or
> so to adopt to the changing nature of the kernel.
>
> Signed-off-by: Arjan van de Ven <[email protected]>
>
> ---
> arch/x86_64/Makefile | 1
> arch/x86_64/kernel/vmlinux.lds.S | 5
> scripts/functionlist | 1286 +++++++++++++++++++++++++++++++++++++++
> scripts/profile2linkerlist.pl | 21
> 4 files changed, 1313 insertions(+)
>
> Index: linux-2.6.16-reorder/arch/x86_64/Makefile
> ===================================================================
> --- linux-2.6.16-reorder.orig/arch/x86_64/Makefile
> +++ linux-2.6.16-reorder/arch/x86_64/Makefile
> @@ -35,6 +35,7 @@ CFLAGS += -m64
> CFLAGS += -mno-red-zone
> CFLAGS += -mcmodel=kernel
> CFLAGS += -pipe
> +CFLAGS += -ffunction-sections
> # this makes reading assembly source easier, but produces worse code
> # actually it makes the kernel smaller too.
> CFLAGS += -fno-reorder-blocks
> Index: linux-2.6.16-reorder/arch/x86_64/kernel/vmlinux.lds.S
> ===================================================================
> --- linux-2.6.16-reorder.orig/arch/x86_64/kernel/vmlinux.lds.S
> +++ linux-2.6.16-reorder/arch/x86_64/kernel/vmlinux.lds.S
> @@ -20,7 +20,12 @@ SECTIONS
> phys_startup_64 = startup_64 - LOAD_OFFSET;
> _text = .; /* Text and read-only data */
> .text : AT(ADDR(.text) - LOAD_OFFSET) {
> + /* First the code that has to be first for bootstrapping */
> *(.bootstrap.text)
> + /* Then all the functions that are "hot" in profiles, to group them
> + onto the same hugetlb entry */
> + #include "../../../scripts/functionlist"
> + /* Then the rest */
> *(.text)
> SCHED_TEXT
> LOCK_TEXT
> Index: linux-2.6.16-reorder/scripts/functionlist
> ===================================================================
> --- /dev/null
> +++ linux-2.6.16-reorder/scripts/functionlist
> @@ -0,0 +1,1286 @@
> +*(.text.flush_thread)
> +*(.text.check_poison_obj)
> +*(.text.copy_page)
> +*(.text.__set_personality)
> +*(.text.gart_map_sg)
> +*(.text.kmem_cache_free)
> +*(.text.find_get_page)
> +*(.text._raw_spin_lock)
> +*(.text.ide_outb)
> +*(.text.unmap_vmas)
> +*(.text.copy_page_range)
> +*(.text.kprobe_handler)
> +*(.text.__handle_mm_fault)
> +*(.text.__d_lookup)
> +*(.text.copy_user_generic)
> +*(.text.__link_path_walk)
> +*(.text.get_page_from_freelist)
> +*(.text.kmem_cache_alloc)
> +*(.text.drive_cmd_intr)
> +*(.text.ia32_setup_sigcontext)
> +*(.text.huge_pte_offset)
> +*(.text.do_page_fault)
> +*(.text.page_remove_rmap)
> +*(.text.release_pages)
> +*(.text.ide_end_request)
> +*(.text.__mutex_lock_slowpath)
> +*(.text.__find_get_block)
> +*(.text.kfree)
> +*(.text.vfs_read)
> +*(.text._raw_spin_unlock)
> +*(.text.free_hot_cold_page)
> +*(.text.fget_light)
> +*(.text.schedule)
> +*(.text.memcmp)
> +*(.text.touch_atime)
> +*(.text.__might_sleep)
> +*(.text.__down_read_trylock)
> +*(.text.arch_pick_mmap_layout)
> +*(.text.find_vma)
> +*(.text.__make_request)
> +*(.text.do_generic_mapping_read)
> +*(.text.mutex_lock_interruptible)
> +*(.text.__generic_file_aio_read)
> +*(.text._atomic_dec_and_lock)
> +*(.text.__wake_up_bit)
> +*(.text.add_to_page_cache)
> +*(.text.cache_alloc_debugcheck_after)
> +*(.text.vm_normal_page)
> +*(.text.mutex_debug_check_no_locks_freed)
> +*(.text.net_rx_action)
> +*(.text.__find_first_zero_bit)
> +*(.text.put_page)
> +*(.text._raw_read_lock)
> +*(.text.__delay)
> +*(.text.dnotify_parent)
> +*(.text.do_path_lookup)
> +*(.text.do_sync_read)
> +*(.text.do_lookup)
> +*(.text.bit_waitqueue)
> +*(.text.file_read_actor)
> +*(.text.strncpy_from_user)
> +*(.text.__pagevec_lru_add_active)
> +*(.text.fget)
> +*(.text.dput)
> +*(.text.__strnlen_user)
> +*(.text.inotify_inode_queue_event)
> +*(.text.rw_verify_area)
> +*(.text.ide_intr)
> +*(.text.inotify_dentry_parent_queue_event)
> +*(.text.permission)
> +*(.text.memscan)
> +*(.text.hpet_rtc_interrupt)
> +*(.text.do_mmap_pgoff)
> +*(.text.current_fs_time)
> +*(.text.vfs_getattr)
> +*(.text.kmem_flagcheck)
> +*(.text.mark_page_accessed)
> +*(.text.free_pages_and_swap_cache)
> +*(.text.generic_fillattr)
> +*(.text.__block_prepare_write)
> +*(.text.__set_page_dirty_nobuffers)
> +*(.text.link_path_walk)
> +*(.text.find_get_pages_tag)
> +*(.text.ide_do_request)
> +*(.text.__alloc_pages)
> +*(.text.generic_permission)
> +*(.text.mod_page_state_offset)
> +*(.text.free_pgd_range)
> +*(.text.generic_file_buffered_write)
> +*(.text.number)
> +*(.text.ide_do_rw_disk)
> +*(.text.__brelse)
> +*(.text.__mod_page_state_offset)
> +*(.text.rotate_reclaimable_page)
> +*(.text.find_vma_prepare)
> +*(.text.find_vma_prev)
> +*(.text.lru_cache_add_active)
> +*(.text.__kmalloc_track_caller)
> +*(.text.smp_invalidate_interrupt)
> +*(.text.handle_IRQ_event)
> +*(.text.__find_get_block_slow)
> +*(.text.do_wp_page)
> +*(.text.do_select)
> +*(.text.set_user_nice)
> +*(.text.sys_read)
> +*(.text.do_munmap)
> +*(.text.csum_partial)
> +*(.text.__do_softirq)
> +*(.text.may_open)
> +*(.text.getname)
> +*(.text.get_empty_filp)
> +*(.text.__fput)
> +*(.text.remove_mapping)
> +*(.text.filp_ctor)
> +*(.text.poison_obj)
> +*(.text.unmap_region)
> +*(.text.test_set_page_writeback)
> +*(.text.__do_page_cache_readahead)
> +*(.text.sock_def_readable)
> +*(.text.ide_outl)
> +*(.text.shrink_zone)
> +*(.text.rb_insert_color)
> +*(.text.get_request)
> +*(.text.sys_pread64)
> +*(.text.spin_bug)
> +*(.text.ide_outsl)
> +*(.text.mask_and_ack_8259A)
> +*(.text.filemap_nopage)
> +*(.text.page_add_file_rmap)
> +*(.text.find_lock_page)
> +*(.text.tcp_poll)
> +*(.text.__mark_inode_dirty)
> +*(.text.file_ra_state_init)
> +*(.text.generic_file_llseek)
> +*(.text.__pagevec_lru_add)
> +*(.text.page_cache_readahead)
> +*(.text.n_tty_receive_buf)
> +*(.text.zonelist_policy)
> +*(.text.vma_adjust)
> +*(.text.test_clear_page_dirty)
> +*(.text.sync_buffer)
> +*(.text.do_exit)
> +*(.text.__bitmap_weight)
> +*(.text.alloc_pages_current)
> +*(.text.get_unused_fd)
> +*(.text.zone_watermark_ok)
> +*(.text.cpuset_update_task_memory_state)
> +*(.text.__bitmap_empty)
> +*(.text.sys_munmap)
> +*(.text.__inode_dir_notify)
> +*(.text.__generic_file_aio_write_nolock)
> +*(.text.__pte_alloc)
> +*(.text.sys_select)
> +*(.text.vm_acct_memory)
> +*(.text.vfs_write)
> +*(.text.__lru_add_drain)
> +*(.text.prio_tree_insert)
> +*(.text.generic_file_aio_read)
> +*(.text.vma_merge)
> +*(.text.block_write_full_page)
> +*(.text.__page_set_anon_rmap)
> +*(.text.apic_timer_interrupt)
> +*(.text.release_console_sem)
> +*(.text.sys_write)
> +*(.text.sys_brk)
> +*(.text.dup_mm)
> +*(.text.read_current_timer)
> +*(.text.ll_rw_block)
> +*(.text.blk_rq_map_sg)
> +*(.text.dbg_userword)
> +*(.text.__block_commit_write)
> +*(.text.cache_grow)
> +*(.text.copy_strings)
> +*(.text.release_task)
> +*(.text.do_sync_write)
> +*(.text.unlock_page)
> +*(.text.load_elf_binary)
> +*(.text.__follow_mount)
> +*(.text.__getblk)
> +*(.text.do_sys_open)
> +*(.text.current_kernel_time)
> +*(.text.call_rcu)
> +*(.text.write_chan)
> +*(.text.vsnprintf)
> +*(.text.dummy_inode_setsecurity)
> +*(.text.submit_bh)
> +*(.text.poll_freewait)
> +*(.text.bio_alloc_bioset)
> +*(.text.skb_clone)
> +*(.text.page_waitqueue)
> +*(.text.__mutex_lock_interruptible_slowpath)
> +*(.text.get_index)
> +*(.text.csum_partial_copy_generic)
> +*(.text.bad_range)
> +*(.text.remove_vma)
> +*(.text.cp_new_stat)
> +*(.text.alloc_arraycache)
> +*(.text.test_clear_page_writeback)
> +*(.text.strsep)
> +*(.text.open_namei)
> +*(.text._raw_read_unlock)
> +*(.text.get_vma_policy)
> +*(.text.__down_write_trylock)
> +*(.text.find_get_pages)
> +*(.text.tcp_rcv_established)
> +*(.text.generic_make_request)
> +*(.text.__block_write_full_page)
> +*(.text.cfq_set_request)
> +*(.text.sys_inotify_init)
> +*(.text.split_vma)
> +*(.text.__mod_timer)
> +*(.text.get_options)
> +*(.text.vma_link)
> +*(.text.mpage_writepages)
> +*(.text.truncate_complete_page)
> +*(.text.tcp_recvmsg)
> +*(.text.sigprocmask)
> +*(.text.filemap_populate)
> +*(.text.sys_close)
> +*(.text.inotify_dev_queue_event)
> +*(.text.do_task_stat)
> +*(.text.__dentry_open)
> +*(.text.unlink_file_vma)
> +*(.text.__pollwait)
> +*(.text.packet_rcv_spkt)
> +*(.text.drop_buffers)
> +*(.text.free_pgtables)
> +*(.text.generic_file_direct_write)
> +*(.text.copy_process)
> +*(.text.netif_receive_skb)
> +*(.text.dnotify_flush)
> +*(.text.print_bad_pte)
> +*(.text.anon_vma_unlink)
> +*(.text.sys_mprotect)
> +*(.text.sync_sb_inodes)
> +*(.text.find_inode_fast)
> +*(.text.dummy_inode_readlink)
> +*(.text.putname)
> +*(.text.init_smp_flush)
> +*(.text.dbg_redzone2)
> +*(.text.sk_run_filter)
> +*(.text.may_expand_vm)
> +*(.text.generic_file_aio_write)
> +*(.text.find_next_zero_bit)
> +*(.text.file_kill)
> +*(.text.audit_getname)
> +*(.text.arch_unmap_area_topdown)
> +*(.text.alloc_page_vma)
> +*(.text.tcp_transmit_skb)
> +*(.text.rb_next)
> +*(.text.dbg_redzone1)
> +*(.text.generic_file_mmap)
> +*(.text.vfs_fstat)
> +*(.text.sys_time)
> +*(.text.page_lock_anon_vma)
> +*(.text.get_unmapped_area)
> +*(.text.remote_llseek)
> +*(.text.__up_read)
> +*(.text.fd_install)
> +*(.text.eventpoll_init_file)
> +*(.text.dma_alloc_coherent)
> +*(.text.create_empty_buffers)
> +*(.text.__mutex_unlock_slowpath)
> +*(.text.dup_fd)
> +*(.text.d_alloc)
> +*(.text.tty_ldisc_try)
> +*(.text.sys_stime)
> +*(.text.__rb_rotate_right)
> +*(.text.d_validate)
> +*(.text.rb_erase)
> +*(.text.path_release)
> +*(.text.memmove)
> +*(.text.invalidate_complete_page)
> +*(.text.clear_inode)
> +*(.text.cache_estimate)
> +*(.text.alloc_buffer_head)
> +*(.text.smp_call_function_interrupt)
> +*(.text.flush_tlb_others)
> +*(.text.file_move)
> +*(.text.balance_dirty_pages_ratelimited)
> +*(.text.vma_prio_tree_add)
> +*(.text.timespec_trunc)
> +*(.text.mempool_alloc)
> +*(.text.iget_locked)
> +*(.text.d_alloc_root)
> +*(.text.cpuset_populate_dir)
> +*(.text.anon_vma_prepare)
> +*(.text.sys_newstat)
> +*(.text.alloc_page_interleave)
> +*(.text.__path_lookup_intent_open)
> +*(.text.__pagevec_free)
> +*(.text.inode_init_once)
> +*(.text.free_vfsmnt)
> +*(.text.__user_walk_fd)
> +*(.text.cfq_idle_slice_timer)
> +*(.text.sys_mmap)
> +*(.text.sys_llseek)
> +*(.text.prio_tree_remove)
> +*(.text.filp_close)
> +*(.text.file_permission)
> +*(.text.vma_prio_tree_remove)
> +*(.text.tcp_ack)
> +*(.text.nameidata_to_filp)
> +*(.text.sys_lseek)
> +*(.text.percpu_counter_mod)
> +*(.text.igrab)
> +*(.text.__bread)
> +*(.text.alloc_inode)
> +*(.text.filldir)
> +*(.text.__rb_rotate_left)
> +*(.text.irq_affinity_write_proc)
> +*(.text.init_request_from_bio)
> +*(.text.find_or_create_page)
> +*(.text.tty_poll)
> +*(.text.tcp_sendmsg)
> +*(.text.ide_wait_stat)
> +*(.text.free_buffer_head)
> +*(.text.flush_signal_handlers)
> +*(.text.tcp_v4_rcv)
> +*(.text.nr_blockdev_pages)
> +*(.text.locks_remove_flock)
> +*(.text.__iowrite32_copy)
> +*(.text.do_filp_open)
> +*(.text.try_to_release_page)
> +*(.text.page_add_new_anon_rmap)
> +*(.text.kmem_cache_size)
> +*(.text.eth_type_trans)
> +*(.text.try_to_free_buffers)
> +*(.text.schedule_tail)
> +*(.text.proc_lookup)
> +*(.text.no_llseek)
> +*(.text.kfree_skbmem)
> +*(.text.do_wait)
> +*(.text.do_mpage_readpage)
> +*(.text.vfs_stat_fd)
> +*(.text.tty_write)
> +*(.text.705)
> +*(.text.sync_page)
> +*(.text.__remove_shared_vm_struct)
> +*(.text.__kfree_skb)
> +*(.text.sock_poll)
> +*(.text.get_request_wait)
> +*(.text.do_sigaction)
> +*(.text.do_brk)
> +*(.text.tcp_event_data_recv)
> +*(.text.read_chan)
> +*(.text.pipe_writev)
> +*(.text.__emul_lookup_dentry)
> +*(.text.rtc_get_rtc_time)
> +*(.text.print_objinfo)
> +*(.text.file_update_time)
> +*(.text.do_signal)
> +*(.text.disable_8259A_irq)
> +*(.text.blk_queue_bounce)
> +*(.text.__anon_vma_link)
> +*(.text.__vma_link)
> +*(.text.vfs_rename)
> +*(.text.sys_newlstat)
> +*(.text.sys_newfstat)
> +*(.text.sys_mknod)
> +*(.text.__show_regs)
> +*(.text.iput)
> +*(.text.get_signal_to_deliver)
> +*(.text.flush_tlb_page)
> +*(.text.debug_mutex_wake_waiter)
> +*(.text.copy_thread)
> +*(.text.clear_page_dirty_for_io)
> +*(.text.buffer_io_error)
> +*(.text.vfs_permission)
> +*(.text.truncate_inode_pages_range)
> +*(.text.sys_recvfrom)
> +*(.text.remove_suid)
> +*(.text.mark_buffer_dirty)
> +*(.text.local_bh_enable)
> +*(.text.get_zeroed_page)
> +*(.text.get_vmalloc_info)
> +*(.text.flush_old_exec)
> +*(.text.dummy_inode_permission)
> +*(.text.__bio_add_page)
> +*(.text.prio_tree_replace)
> +*(.text.notify_change)
> +*(.text.mntput_no_expire)
> +*(.text.fput)
> +*(.text.__end_that_request_first)
> +*(.text.wake_up_bit)
> +*(.text.unuse_mm)
> +*(.text.skb_release_data)
> +*(.text.shrink_icache_memory)
> +*(.text.sched_balance_self)
> +*(.text.__pmd_alloc)
> +*(.text.pipe_poll)
> +*(.text.normal_poll)
> +*(.text.__free_pages)
> +*(.text.follow_mount)
> +*(.text.cdrom_start_packet_command)
> +*(.text.blk_recount_segments)
> +*(.text.bio_put)
> +*(.text.__alloc_skb)
> +*(.text.__wake_up)
> +*(.text.vm_stat_account)
> +*(.text.sys_fcntl)
> +*(.text.sys_fadvise64)
> +*(.text._raw_write_unlock)
> +*(.text.__pud_alloc)
> +*(.text.alloc_page_buffers)
> +*(.text.vfs_llseek)
> +*(.text.sockfd_lookup)
> +*(.text._raw_write_lock)
> +*(.text.put_compound_page)
> +*(.text.prune_dcache)
> +*(.text.pipe_readv)
> +*(.text.mempool_free)
> +*(.text.make_ahead_window)
> +*(.text.lru_add_drain)
> +*(.text.constant_test_bit)
> +*(.text.__clear_user)
> +*(.text.arch_unmap_area)
> +*(.text.anon_vma_link)
> +*(.text.sys_chroot)
> +*(.text.setup_arg_pages)
> +*(.text.radix_tree_preload)
> +*(.text.init_rwsem)
> +*(.text.generic_osync_inode)
> +*(.text.generic_delete_inode)
> +*(.text.do_sys_poll)
> +*(.text.dev_queue_xmit)
> +*(.text.default_llseek)
> +*(.text.__writeback_single_inode)
> +*(.text.vfs_ioctl)
> +*(.text.__up_write)
> +*(.text.unix_poll)
> +*(.text.sys_rt_sigprocmask)
> +*(.text.sock_recvmsg)
> +*(.text.recalc_bh_state)
> +*(.text.__put_unused_fd)
> +*(.text.process_backlog)
> +*(.text.locks_remove_posix)
> +*(.text.lease_modify)
> +*(.text.expand_files)
> +*(.text.end_buffer_read_nobh)
> +*(.text.d_splice_alias)
> +*(.text.debug_mutex_init_waiter)
> +*(.text.copy_from_user)
> +*(.text.cap_vm_enough_memory)
> +*(.text.show_vfsmnt)
> +*(.text.release_sock)
> +*(.text.pfifo_fast_enqueue)
> +*(.text.half_md4_transform)
> +*(.text.fs_may_remount_ro)
> +*(.text.do_fork)
> +*(.text.copy_hugetlb_page_range)
> +*(.text.cache_free_debugcheck)
> +*(.text.__tcp_select_window)
> +*(.text.task_handoff_register)
> +*(.text.sys_open)
> +*(.text.strlcpy)
> +*(.text.skb_copy_datagram_iovec)
> +*(.text.set_up_list3s)
> +*(.text.release_open_intent)
> +*(.text.qdisc_restart)
> +*(.text.n_tty_chars_in_buffer)
> +*(.text.inode_change_ok)
> +*(.text.__downgrade_write)
> +*(.text.debug_mutex_unlock)
> +*(.text.add_timer_randomness)
> +*(.text.sock_common_recvmsg)
> +*(.text.set_bh_page)
> +*(.text.printk_lock)
> +*(.text.path_release_on_umount)
> +*(.text.ip_output)
> +*(.text.ide_build_dmatable)
> +*(.text.__get_user_8)
> +*(.text.end_buffer_read_sync)
> +*(.text.__d_path)
> +*(.text.d_move)
> +*(.text.del_timer)
> +*(.text.constant_test_bit)
> +*(.text.blockable_page_cache_readahead)
> +*(.text.tty_read)
> +*(.text.sys_readlink)
> +*(.text.sys_faccessat)
> +*(.text.read_swap_cache_async)
> +*(.text.pty_write_room)
> +*(.text.page_address_in_vma)
> +*(.text.kthread)
> +*(.text.cfq_exit_io_context)
> +*(.text.__tcp_push_pending_frames)
> +*(.text.sys_pipe)
> +*(.text.submit_bio)
> +*(.text.pid_revalidate)
> +*(.text.page_referenced_file)
> +*(.text.lock_sock)
> +*(.text.get_page_state_node)
> +*(.text.generic_block_bmap)
> +*(.text.do_setitimer)
> +*(.text.dev_queue_xmit_nit)
> +*(.text.copy_from_read_buf)
> +*(.text.__const_udelay)
> +*(.text.console_conditional_schedule)
> +*(.text.wake_up_new_task)
> +*(.text.wait_for_completion_interruptible)
> +*(.text.tcp_rcv_rtt_update)
> +*(.text.sys_mlockall)
> +*(.text.set_fs_altroot)
> +*(.text.schedule_timeout)
> +*(.text.nr_free_pagecache_pages)
> +*(.text.nf_iterate)
> +*(.text.mapping_tagged)
> +*(.text.ip_queue_xmit)
> +*(.text.ip_local_deliver)
> +*(.text.follow_page)
> +*(.text.elf_map)
> +*(.text.dummy_file_permission)
> +*(.text.dispose_list)
> +*(.text.dentry_open)
> +*(.text.dentry_iput)
> +*(.text.bio_alloc)
> +*(.text.alloc_skb_from_cache)
> +*(.text.wait_on_page_bit)
> +*(.text.vfs_readdir)
> +*(.text.vfs_lstat)
> +*(.text.seq_escape)
> +*(.text.__posix_lock_file)
> +*(.text.mm_release)
> +*(.text.kref_put)
> +*(.text.ip_rcv)
> +*(.text.__iget)
> +*(.text.free_pages)
> +*(.text.find_mergeable_anon_vma)
> +*(.text.find_extend_vma)
> +*(.text.dummy_inode_listsecurity)
> +*(.text.bio_add_page)
> +*(.text.__vm_enough_memory)
> +*(.text.vfs_stat)
> +*(.text.tty_paranoia_check)
> +*(.text.tcp_read_sock)
> +*(.text.tcp_data_queue)
> +*(.text.sys_uname)
> +*(.text.sys_renameat)
> +*(.text.__strncpy_from_user)
> +*(.text.__mutex_init)
> +*(.text.__lookup_hash)
> +*(.text.kref_get)
> +*(.text.ip_route_input)
> +*(.text.__insert_inode_hash)
> +*(.text.do_sock_write)
> +*(.text.blk_done_softirq)
> +*(.text.__wake_up_sync)
> +*(.text.__vma_link_rb)
> +*(.text.tty_ioctl)
> +*(.text.tracesys)
> +*(.text.sys_getdents)
> +*(.text.sys_dup)
> +*(.text.stub_execve)
> +*(.text.sha_transform)
> +*(.text.radix_tree_tag_clear)
> +*(.text.put_unused_fd)
> +*(.text.put_files_struct)
> +*(.text.mpage_readpages)
> +*(.text.may_delete)
> +*(.text.kmem_cache_create)
> +*(.text.ip_mc_output)
> +*(.text.interleave_nodes)
> +*(.text.groups_search)
> +*(.text.generic_drop_inode)
> +*(.text.generic_commit_write)
> +*(.text.fcntl_setlk)
> +*(.text.exit_mmap)
> +*(.text.end_page_writeback)
> +*(.text.__d_rehash)
> +*(.text.debug_mutex_free_waiter)
> +*(.text.csum_ipv6_magic)
> +*(.text.count)
> +*(.text.cleanup_rbuf)
> +*(.text.check_spinlock_acquired_node)
> +*(.text.can_vma_merge_after)
> +*(.text.bio_endio)
> +*(.text.alloc_pidmap)
> +*(.text.write_ldt)
> +*(.text.vmtruncate_range)
> +*(.text.vfs_create)
> +*(.text.__user_walk)
> +*(.text.update_send_head)
> +*(.text.unmap_underlying_metadata)
> +*(.text.tty_ldisc_deref)
> +*(.text.tcp_setsockopt)
> +*(.text.tcp_send_ack)
> +*(.text.sys_pause)
> +*(.text.sys_gettimeofday)
> +*(.text.sync_dirty_buffer)
> +*(.text.strncmp)
> +*(.text.release_posix_timer)
> +*(.text.proc_file_read)
> +*(.text.prepare_to_wait)
> +*(.text.locks_mandatory_locked)
> +*(.text.interruptible_sleep_on_timeout)
> +*(.text.inode_sub_bytes)
> +*(.text.in_group_p)
> +*(.text.hrtimer_try_to_cancel)
> +*(.text.filldir64)
> +*(.text.fasync_helper)
> +*(.text.dummy_sb_pivotroot)
> +*(.text.d_lookup)
> +*(.text.d_instantiate)
> +*(.text.__d_find_alias)
> +*(.text.cpu_idle_wait)
> +*(.text.cond_resched_lock)
> +*(.text.chown_common)
> +*(.text.blk_congestion_wait)
> +*(.text.activate_page)
> +*(.text.unlock_buffer)
> +*(.text.tty_wakeup)
> +*(.text.tcp_v4_do_rcv)
> +*(.text.tcp_current_mss)
> +*(.text.sys_openat)
> +*(.text.sys_fchdir)
> +*(.text.strnlen_user)
> +*(.text.strnlen)
> +*(.text.strchr)
> +*(.text.sock_common_getsockopt)
> +*(.text.skb_checksum)
> +*(.text.remove_wait_queue)
> +*(.text.rb_replace_node)
> +*(.text.radix_tree_node_ctor)
> +*(.text.pty_chars_in_buffer)
> +*(.text.profile_hit)
> +*(.text.prio_tree_left)
> +*(.text.pgd_clear_bad)
> +*(.text.pfifo_fast_dequeue)
> +*(.text.page_referenced)
> +*(.text.open_exec)
> +*(.text.mmput)
> +*(.text.mm_init)
> +*(.text.__ide_dma_off_quietly)
> +*(.text.ide_dma_intr)
> +*(.text.hrtimer_start)
> +*(.text.get_io_context)
> +*(.text.__get_free_pages)
> +*(.text.find_first_zero_bit)
> +*(.text.file_free_rcu)
> +*(.text.dummy_socket_sendmsg)
> +*(.text.do_unlinkat)
> +*(.text.do_arch_prctl)
> +*(.text.destroy_inode)
> +*(.text.can_vma_merge_before)
> +*(.text.block_sync_page)
> +*(.text.block_prepare_write)
> +*(.text.bio_init)
> +*(.text.arch_ptrace)
> +*(.text.wake_up_inode)
> +*(.text.wait_on_retry_sync_kiocb)
> +*(.text.vma_prio_tree_next)
> +*(.text.tcp_rcv_space_adjust)
> +*(.text.__tcp_ack_snd_check)
> +*(.text.sys_utime)
> +*(.text.sys_recvmsg)
> +*(.text.sys_mremap)
> +*(.text.sys_bdflush)
> +*(.text.sleep_on)
> +*(.text.set_page_dirty_lock)
> +*(.text.seq_path)
> +*(.text.schedule_timeout_interruptible)
> +*(.text.sched_fork)
> +*(.text.rt_run_flush)
> +*(.text.profile_munmap)
> +*(.text.prepare_binprm)
> +*(.text.__pagevec_release_nonlru)
> +*(.text.m_show)
> +*(.text.lookup_mnt)
> +*(.text.__lookup_mnt)
> +*(.text.lock_timer_base)
> +*(.text.is_subdir)
> +*(.text.invalidate_bh_lru)
> +*(.text.init_buffer_head)
> +*(.text.ifind_fast)
> +*(.text.ide_dma_start)
> +*(.text.__get_page_state)
> +*(.text.flock_to_posix_lock)
> +*(.text.__find_symbol)
> +*(.text.do_futex)
> +*(.text.do_execve)
> +*(.text.dirty_writeback_centisecs_handler)
> +*(.text.dev_watchdog)
> +*(.text.can_share_swap_page)
> +*(.text.blkdev_put)
> +*(.text.bio_get_nr_vecs)
> +*(.text.xfrm_compile_policy)
> +*(.text.vma_prio_tree_insert)
> +*(.text.vfs_lstat_fd)
> +*(.text.__user_path_lookup_open)
> +*(.text.thread_return)
> +*(.text.tcp_send_delayed_ack)
> +*(.text.sock_def_error_report)
> +*(.text.shrink_slab)
> +*(.text.serial_out)
> +*(.text.seq_read)
> +*(.text.secure_ip_id)
> +*(.text.search_binary_handler)
> +*(.text.proc_pid_unhash)
> +*(.text.pagevec_lookup)
> +*(.text.new_inode)
> +*(.text.memcpy_toiovec)
> +*(.text.locks_free_lock)
> +*(.text.__lock_page)
> +*(.text.__lock_buffer)
> +*(.text.load_module)
> +*(.text.is_bad_inode)
> +*(.text.invalidate_inode_buffers)
> +*(.text.insert_vm_struct)
> +*(.text.inode_setattr)
> +*(.text.inode_add_bytes)
> +*(.text.ide_read_24)
> +*(.text.ide_get_error_location)
> +*(.text.ide_do_drive_cmd)
> +*(.text.get_locked_pte)
> +*(.text.get_filesystem_list)
> +*(.text.generic_file_open)
> +*(.text.follow_down)
> +*(.text.find_next_bit)
> +*(.text.__find_first_bit)
> +*(.text.exit_mm)
> +*(.text.exec_keys)
> +*(.text.end_buffer_write_sync)
> +*(.text.end_bio_bh_io_sync)
> +*(.text.dummy_socket_shutdown)
> +*(.text.d_rehash)
> +*(.text.d_path)
> +*(.text.do_ioctl)
> +*(.text.dget_locked)
> +*(.text.copy_thread_group_keys)
> +*(.text.cdrom_end_request)
> +*(.text.cap_bprm_apply_creds)
> +*(.text.blk_rq_bio_prep)
> +*(.text.__bitmap_intersects)
> +*(.text.bio_phys_segments)
> +*(.text.bio_free)
> +*(.text.arch_get_unmapped_area_topdown)
> +*(.text.writeback_in_progress)
> +*(.text.vfs_follow_link)
> +*(.text.tcp_rcv_state_process)
> +*(.text.tcp_check_space)
> +*(.text.sys_stat)
> +*(.text.sys_rt_sigreturn)
> +*(.text.sys_rt_sigaction)
> +*(.text.sys_remap_file_pages)
> +*(.text.sys_pwrite64)
> +*(.text.sys_fchownat)
> +*(.text.sys_fchmodat)
> +*(.text.strncat)
> +*(.text.strlcat)
> +*(.text.strcmp)
> +*(.text.steal_locks)
> +*(.text.sock_create)
> +*(.text.sk_stream_rfree)
> +*(.text.sk_stream_mem_schedule)
> +*(.text.skip_atoi)
> +*(.text.sk_alloc)
> +*(.text.show_stat)
> +*(.text.set_fs_pwd)
> +*(.text.set_binfmt)
> +*(.text.pty_unthrottle)
> +*(.text.proc_symlink)
> +*(.text.pipe_release)
> +*(.text.pageout)
> +*(.text.n_tty_write_wakeup)
> +*(.text.n_tty_ioctl)
> +*(.text.nr_free_zone_pages)
> +*(.text.migration_thread)
> +*(.text.mempool_free_slab)
> +*(.text.meminfo_read_proc)
> +*(.text.max_sane_readahead)
> +*(.text.lru_cache_add)
> +*(.text.kill_fasync)
> +*(.text.kernel_read)
> +*(.text.invalidate_mapping_pages)
> +*(.text.inode_has_buffers)
> +*(.text.init_once)
> +*(.text.inet_sendmsg)
> +*(.text.idedisk_issue_flush)
> +*(.text.generic_file_write)
> +*(.text.free_more_memory)
> +*(.text.__free_fdtable)
> +*(.text.filp_dtor)
> +*(.text.exit_sem)
> +*(.text.exit_itimers)
> +*(.text.error_interrupt)
> +*(.text.end_buffer_async_write)
> +*(.text.eligible_child)
> +*(.text.elf_map)
> +*(.text.dump_task_regs)
> +*(.text.dummy_task_setscheduler)
> +*(.text.dummy_socket_accept)
> +*(.text.dummy_file_free_security)
> +*(.text.__down_read)
> +*(.text.do_sock_read)
> +*(.text.do_sigaltstack)
> +*(.text.do_mremap)
> +*(.text.current_io_context)
> +*(.text.cpu_swap_callback)
> +*(.text.copy_vma)
> +*(.text.cap_bprm_set_security)
> +*(.text.blk_insert_request)
> +*(.text.bio_map_kern_endio)
> +*(.text.bio_hw_segments)
> +*(.text.bictcp_cong_avoid)
> +*(.text.add_interrupt_randomness)
> +*(.text.wait_for_completion)
> +*(.text.version_read_proc)
> +*(.text.unix_write_space)
> +*(.text.tty_ldisc_ref_wait)
> +*(.text.tty_ldisc_put)
> +*(.text.try_to_wake_up)
> +*(.text.tcp_v4_tw_remember_stamp)
> +*(.text.tcp_try_undo_dsack)
> +*(.text.tcp_may_send_now)
> +*(.text.sys_waitid)
> +*(.text.sys_sched_getparam)
> +*(.text.sys_getppid)
> +*(.text.sys_getcwd)
> +*(.text.sys_dup2)
> +*(.text.sys_chmod)
> +*(.text.sys_chdir)
> +*(.text.sprintf)
> +*(.text.sock_wfree)
> +*(.text.sock_aio_write)
> +*(.text.skb_drop_fraglist)
> +*(.text.skb_dequeue)
> +*(.text.set_close_on_exec)
> +*(.text.set_brk)
> +*(.text.seq_puts)
> +*(.text.SELECT_DRIVE)
> +*(.text.sched_exec)
> +*(.text.return_EIO)
> +*(.text.remove_from_page_cache)
> +*(.text.rcu_start_batch)
> +*(.text.__put_task_struct)
> +*(.text.proc_pid_readdir)
> +*(.text.proc_get_inode)
> +*(.text.prepare_to_wait_exclusive)
> +*(.text.pipe_wait)
> +*(.text.pipe_new)
> +*(.text.pdflush_operation)
> +*(.text.__pagevec_release)
> +*(.text.pagevec_lookup_tag)
> +*(.text.packet_rcv)
> +*(.text.n_tty_set_room)
> +*(.text.nr_free_pages)
> +*(.text.__net_timestamp)
> +*(.text.mpage_end_io_read)
> +*(.text.mod_timer)
> +*(.text.__memcpy)
> +*(.text.mb_cache_shrink_fn)
> +*(.text.lock_rename)
> +*(.text.kstrdup)
> +*(.text.is_ignored)
> +*(.text.int_very_careful)
> +*(.text.inotify_inode_is_dead)
> +*(.text.inotify_get_cookie)
> +*(.text.inode_get_bytes)
> +*(.text.init_timer)
> +*(.text.init_dev)
> +*(.text.inet_getname)
> +*(.text.ide_map_sg)
> +*(.text.__ide_dma_end)
> +*(.text.hrtimer_get_remaining)
> +*(.text.get_task_mm)
> +*(.text.get_random_int)
> +*(.text.free_pipe_info)
> +*(.text.filemap_write_and_wait_range)
> +*(.text.exit_thread)
> +*(.text.enter_idle)
> +*(.text.end_that_request_first)
> +*(.text.end_8259A_irq)
> +*(.text.dummy_file_alloc_security)
> +*(.text.do_group_exit)
> +*(.text.debug_mutex_init)
> +*(.text.cpuset_exit)
> +*(.text.cpu_idle)
> +*(.text.copy_semundo)
> +*(.text.copy_files)
> +*(.text.chrdev_open)
> +*(.text.cdrom_transfer_packet_command)
> +*(.text.cdrom_mode_sense)
> +*(.text.blk_phys_contig_segment)
> +*(.text.blk_get_queue)
> +*(.text.bio_split)
> +*(.text.audit_alloc)
> +*(.text.anon_pipe_buf_release)
> +*(.text.add_wait_queue_exclusive)
> +*(.text.add_wait_queue)
> +*(.text.acct_process)
> +*(.text.account)
> +*(.text.zeromap_page_range)
> +*(.text.yield)
> +*(.text.writeback_acquire)
> +*(.text.worker_thread)
> +*(.text.wait_on_page_writeback_range)
> +*(.text.__wait_on_buffer)
> +*(.text.vscnprintf)
> +*(.text.vmalloc_to_pfn)
> +*(.text.vgacon_save_screen)
> +*(.text.vfs_unlink)
> +*(.text.vfs_rmdir)
> +*(.text.unregister_md_personality)
> +*(.text.unlock_new_inode)
> +*(.text.unix_stream_sendmsg)
> +*(.text.unix_stream_recvmsg)
> +*(.text.unhash_process)
> +*(.text.udp_v4_lookup_longway)
> +*(.text.tty_ldisc_flush)
> +*(.text.tty_ldisc_enable)
> +*(.text.tty_hung_up_p)
> +*(.text.tty_buffer_free_all)
> +*(.text.tso_fragment)
> +*(.text.try_to_del_timer_sync)
> +*(.text.tcp_v4_err)
> +*(.text.tcp_unhash)
> +*(.text.tcp_seq_next)
> +*(.text.tcp_select_initial_window)
> +*(.text.tcp_sacktag_write_queue)
> +*(.text.tcp_cwnd_validate)
> +*(.text.sys_vhangup)
> +*(.text.sys_uselib)
> +*(.text.sys_symlink)
> +*(.text.sys_signal)
> +*(.text.sys_poll)
> +*(.text.sys_mount)
> +*(.text.sys_kill)
> +*(.text.sys_ioctl)
> +*(.text.sys_inotify_add_watch)
> +*(.text.sys_getuid)
> +*(.text.sys_getrlimit)
> +*(.text.sys_getitimer)
> +*(.text.sys_getgroups)
> +*(.text.sys_ftruncate)
> +*(.text.sysfs_lookup)
> +*(.text.sys_exit_group)
> +*(.text.stub_fork)
> +*(.text.sscanf)
> +*(.text.sock_map_fd)
> +*(.text.sock_get_timestamp)
> +*(.text.__sock_create)
> +*(.text.smp_call_function_single)
> +*(.text.sk_stop_timer)
> +*(.text.skb_copy_and_csum_datagram)
> +*(.text.__skb_checksum_complete)
> +*(.text.single_next)
> +*(.text.sigqueue_alloc)
> +*(.text.shrink_dcache_parent)
> +*(.text.select_idle_routine)
> +*(.text.run_workqueue)
> +*(.text.run_local_timers)
> +*(.text.remove_inode_hash)
> +*(.text.remove_dquot_ref)
> +*(.text.register_binfmt)
> +*(.text.read_cache_pages)
> +*(.text.rb_last)
> +*(.text.pty_open)
> +*(.text.proc_root_readdir)
> +*(.text.proc_pid_flush)
> +*(.text.proc_pident_lookup)
> +*(.text.proc_fill_super)
> +*(.text.proc_exe_link)
> +*(.text.posix_locks_deadlock)
> +*(.text.pipe_iov_copy_from_user)
> +*(.text.opost)
> +*(.text.nf_register_hook)
> +*(.text.netif_rx_ni)
> +*(.text.m_start)
> +*(.text.mpage_writepage)
> +*(.text.mm_alloc)
> +*(.text.memory_open)
> +*(.text.mark_buffer_async_write)
> +*(.text.lru_add_drain_all)
> +*(.text.locks_init_lock)
> +*(.text.locks_delete_lock)
> +*(.text.lock_hrtimer_base)
> +*(.text.load_script)
> +*(.text.__kill_fasync)
> +*(.text.ip_mc_sf_allow)
> +*(.text.__ioremap)
> +*(.text.int_with_check)
> +*(.text.int_sqrt)
> +*(.text.install_thread_keyring)
> +*(.text.init_page_buffers)
> +*(.text.inet_sock_destruct)
> +*(.text.idle_notifier_register)
> +*(.text.ide_execute_command)
> +*(.text.ide_end_drive_cmd)
> +*(.text.__ide_dma_host_on)
> +*(.text.hrtimer_run_queues)
> +*(.text.hpet_mask_rtc_irq_bit)
> +*(.text.__get_zone_counts)
> +*(.text.get_zone_counts)
> +*(.text.get_write_access)
> +*(.text.get_fs_struct)
> +*(.text.get_dirty_limits)
> +*(.text.generic_readlink)
> +*(.text.free_hot_page)
> +*(.text.finish_wait)
> +*(.text.find_inode)
> +*(.text.find_first_bit)
> +*(.text.__filemap_fdatawrite_range)
> +*(.text.__filemap_copy_from_user_iovec)
> +*(.text.exit_aio)
> +*(.text.elv_set_request)
> +*(.text.elv_former_request)
> +*(.text.dup_namespace)
> +*(.text.dupfd)
> +*(.text.dummy_socket_getsockopt)
> +*(.text.dummy_sb_post_mountroot)
> +*(.text.dummy_quotactl)
> +*(.text.dummy_inode_rename)
> +*(.text.__do_SAK)
> +*(.text.do_pipe)
> +*(.text.do_fsync)
> +*(.text.d_instantiate_unique)
> +*(.text.d_find_alias)
> +*(.text.deny_write_access)
> +*(.text.dentry_unhash)
> +*(.text.d_delete)
> +*(.text.datagram_poll)
> +*(.text.cpuset_fork)
> +*(.text.cpuid_read)
> +*(.text.copy_namespace)
> +*(.text.cond_resched)
> +*(.text.check_version)
> +*(.text.__change_page_attr)
> +*(.text.cfq_slab_kill)
> +*(.text.cfq_completed_request)
> +*(.text.cdrom_pc_intr)
> +*(.text.cdrom_decode_status)
> +*(.text.cap_capset_check)
> +*(.text.blk_put_request)
> +*(.text.bio_fs_destructor)
> +*(.text.bictcp_min_cwnd)
> +*(.text.alloc_chrdev_region)
> +*(.text.add_element)
> +*(.text.acct_update_integrals)
> +*(.text.write_boundary_block)
> +*(.text.writeback_release)
> +*(.text.writeback_inodes)
> +*(.text.wake_up_state)
> +*(.text.__wake_up_locked)
> +*(.text.wake_futex)
> +*(.text.wait_task_inactive)
> +*(.text.__wait_on_freeing_inode)
> +*(.text.wait_noreap_copyout)
> +*(.text.vmstat_start)
> +*(.text.vgacon_do_font_op)
> +*(.text.vfs_readv)
> +*(.text.vfs_quota_sync)
> +*(.text.update_queue)
> +*(.text.unshare_files)
> +*(.text.unmap_vm_area)
> +*(.text.unix_socketpair)
> +*(.text.unix_release_sock)
> +*(.text.unix_detach_fds)
> +*(.text.unix_create1)
> +*(.text.unix_bind)
> +*(.text.udp_sendmsg)
> +*(.text.udp_rcv)
> +*(.text.udp_queue_rcv_skb)
> +*(.text.uart_write)
> +*(.text.uart_startup)
> +*(.text.uart_open)
> +*(.text.tty_vhangup)
> +*(.text.tty_termios_baud_rate)
> +*(.text.tty_release)
> +*(.text.tty_ldisc_ref)
> +*(.text.throttle_vm_writeout)
> +*(.text.058)
> +*(.text.tcp_xmit_probe_skb)
> +*(.text.tcp_v4_send_check)
> +*(.text.tcp_v4_destroy_sock)
> +*(.text.tcp_sync_mss)
> +*(.text.tcp_snd_test)
> +*(.text.tcp_slow_start)
> +*(.text.tcp_send_fin)
> +*(.text.tcp_rtt_estimator)
> +*(.text.tcp_parse_options)
> +*(.text.tcp_ioctl)
> +*(.text.tcp_init_tso_segs)
> +*(.text.tcp_init_cwnd)
> +*(.text.tcp_getsockopt)
> +*(.text.tcp_fin)
> +*(.text.tcp_connect)
> +*(.text.tcp_cong_avoid)
> +*(.text.__tcp_checksum_complete_user)
> +*(.text.task_dumpable)
> +*(.text.sys_wait4)
> +*(.text.sys_utimes)
> +*(.text.sys_symlinkat)
> +*(.text.sys_socketpair)
> +*(.text.sys_rmdir)
> +*(.text.sys_readahead)
> +*(.text.sys_nanosleep)
> +*(.text.sys_linkat)
> +*(.text.sys_fstat)
> +*(.text.sysfs_readdir)
> +*(.text.sys_execve)
> +*(.text.sysenter_tracesys)
> +*(.text.sys_chown)
> +*(.text.stub_clone)
> +*(.text.strrchr)
> +*(.text.strncpy)
> +*(.text.stopmachine_set_state)
> +*(.text.sock_sendmsg)
> +*(.text.sock_release)
> +*(.text.sock_fasync)
> +*(.text.sock_close)
> +*(.text.sk_stream_write_space)
> +*(.text.sk_reset_timer)
> +*(.text.skb_split)
> +*(.text.skb_recv_datagram)
> +*(.text.skb_queue_tail)
> +*(.text.sk_attach_filter)
> +*(.text.si_swapinfo)
> +*(.text.simple_strtoll)
> +*(.text.set_termios)
> +*(.text.set_task_comm)
> +*(.text.set_shrinker)
> +*(.text.set_normalized_timespec)
> +*(.text.set_brk)
> +*(.text.serial_in)
> +*(.text.seq_printf)
> +*(.text.secure_dccp_sequence_number)
> +*(.text.rwlock_bug)
> +*(.text.rt_hash_code)
> +*(.text.__rta_fill)
> +*(.text.__request_resource)
> +*(.text.relocate_new_kernel)
> +*(.text.release_thread)
> +*(.text.release_mem)
> +*(.text.rb_prev)
> +*(.text.rb_first)
> +*(.text.random_poll)
> +*(.text.__put_super_and_need_restart)
> +*(.text.pty_write)
> +*(.text.ptrace_stop)
> +*(.text.proc_self_readlink)
> +*(.text.proc_root_lookup)
> +*(.text.proc_root_link)
> +*(.text.proc_pid_make_inode)
> +*(.text.proc_pid_attr_write)
> +*(.text.proc_lookupfd)
> +*(.text.proc_delete_inode)
> +*(.text.posix_same_owner)
> +*(.text.posix_block_lock)
> +*(.text.poll_initwait)
> +*(.text.pipe_write)
> +*(.text.pipe_read_fasync)
> +*(.text.pipe_ioctl)
> +*(.text.pdflush)
> +*(.text.pci_user_read_config_dword)
> +*(.text.page_readlink)
> +*(.text.null_lseek)
> +*(.text.nf_hook_slow)
> +*(.text.netlink_sock_destruct)
> +*(.text.netlink_broadcast)
> +*(.text.neigh_resolve_output)
> +*(.text.name_to_int)
> +*(.text.mwait_idle)
> +*(.text.mutex_trylock)
> +*(.text.mutex_debug_check_no_locks_held)
> +*(.text.m_stop)
> +*(.text.mpage_end_io_write)
> +*(.text.mpage_alloc)
> +*(.text.move_page_tables)
> +*(.text.mounts_open)
> +*(.text.__memset)
> +*(.text.memcpy_fromiovec)
> +*(.text.make_8259A_irq)
> +*(.text.lookup_user_key_possessed)
> +*(.text.lookup_create)
> +*(.text.locks_insert_lock)
> +*(.text.locks_alloc_lock)
> +*(.text.kthread_should_stop)
> +*(.text.kswapd)
> +*(.text.kobject_uevent)
> +*(.text.kobject_get_path)
> +*(.text.kobject_get)
> +*(.text.klist_children_put)
> +*(.text.__ip_route_output_key)
> +*(.text.ip_flush_pending_frames)
> +*(.text.ip_compute_csum)
> +*(.text.ip_append_data)
> +*(.text.ioc_set_batching)
> +*(.text.invalidate_inode_pages)
> +*(.text.__invalidate_device)
> +*(.text.install_arg_page)
> +*(.text.in_sched_functions)
> +*(.text.inotify_unmount_inodes)
> +*(.text.init_once)
> +*(.text.init_cdrom_command)
> +*(.text.inet_stream_connect)
> +*(.text.inet_sk_rebuild_header)
> +*(.text.inet_csk_addr2sockaddr)
> +*(.text.inet_create)
> +*(.text.ifind)
> +*(.text.ide_setup_dma)
> +*(.text.ide_outsw)
> +*(.text.ide_fixstring)
> +*(.text.ide_dma_setup)
> +*(.text.ide_cdrom_packet)
> +*(.text.ide_cd_put)
> +*(.text.ide_build_sglist)
> +*(.text.i8259A_shutdown)
> +*(.text.hung_up_tty_ioctl)
> +*(.text.hrtimer_nanosleep)
> +*(.text.hrtimer_init)
> +*(.text.hrtimer_cancel)
> +*(.text.hash_futex)
> +*(.text.group_send_sig_info)
> +*(.text.grab_cache_page_nowait)
> +*(.text.get_wchan)
> +*(.text.get_stack)
> +*(.text.get_page_state)
> +*(.text.getnstimeofday)
> +*(.text.get_node)
> +*(.text.get_kprobe)
> +*(.text.generic_unplug_device)
> +*(.text.free_task)
> +*(.text.frag_show)
> +*(.text.find_next_zero_string)
> +*(.text.filp_open)
> +*(.text.fillonedir)
> +*(.text.exit_io_context)
> +*(.text.exit_idle)
> +*(.text.exact_lock)
> +*(.text.eth_header)
> +*(.text.dummy_unregister_security)
> +*(.text.dummy_socket_post_create)
> +*(.text.dummy_socket_listen)
> +*(.text.dummy_quota_on)
> +*(.text.dummy_inode_follow_link)
> +*(.text.dummy_file_receive)
> +*(.text.dummy_file_mprotect)
> +*(.text.dummy_file_lock)
> +*(.text.dummy_file_ioctl)
> +*(.text.dummy_bprm_post_apply_creds)
> +*(.text.do_writepages)
> +*(.text.__down_interruptible)
> +*(.text.do_notify_resume)
> +*(.text.do_acct_process)
> +*(.text.del_timer_sync)
> +*(.text.default_rebuild_header)
> +*(.text.d_callback)
> +*(.text.dcache_readdir)
> +*(.text.ctrl_dumpfamily)
> +*(.text.cpuset_rmdir)
> +*(.text.copy_strings_kernel)
> +*(.text.con_write_room)
> +*(.text.complete_all)
> +*(.text.collect_sigign_sigcatch)
> +*(.text.clear_user)
> +*(.text.check_unthrottle)
> +*(.text.cdrom_release)
> +*(.text.cdrom_newpc_intr)
> +*(.text.cdrom_ioctl)
> +*(.text.cdrom_check_status)
> +*(.text.cdev_put)
> +*(.text.cdev_add)
> +*(.text.cap_ptrace)
> +*(.text.cap_bprm_secureexec)
> +*(.text.cache_alloc_refill)
> +*(.text.bmap)
> +*(.text.blk_run_queue)
> +*(.text.blk_queue_dma_alignment)
> +*(.text.blk_ordered_req_seq)
> +*(.text.blk_backing_dev_unplug)
> +*(.text.__bitmap_subset)
> +*(.text.__bitmap_and)
> +*(.text.bio_unmap_user)
> +*(.text.__bforget)
> +*(.text.bd_forget)
> +*(.text.bad_pipe_w)
> +*(.text.bad_get_user)
> +*(.text.audit_free)
> +*(.text.anon_vma_ctor)
> +*(.text.anon_pipe_buf_map)
> +*(.text.alloc_sock_iocb)
> +*(.text.alloc_fdset)
> +*(.text.aio_kick_handler)
> +*(.text.__add_entropy_words)
> +*(.text.add_disk_randomness)
> Index: linux-2.6.16-reorder/scripts/profile2linkerlist.pl
> ===================================================================
> --- /dev/null
> +++ linux-2.6.16-reorder/scripts/profile2linkerlist.pl
> @@ -0,0 +1,21 @@
> +#!/usr/bin/perl
> +
> +#
> +# Takes a (sorted) output of readprofile and turns it into a list suitable for
> +# linker scripts
> +#
> +# usage:
> +# readprofile | sort -rn | perl profile2linkerlist.pl > functionlist
> +#
> +
> +while (<>) {
> + my $line = $_;
> +
> + $_ =~ /\W*[0-9]+\W*([a-zA-Z\_0-9]+)\W*[0-9]+/;
> +
> + if ( ($line =~ /unknown/) || ($line =~ /total/)) {
> +
> + } else {
> + print "*(.text.$1)\n";
> + }
> +}
>
> -

This is the dumbest thing I've seen in recent years! You should
put all the stuff you want to hit with one TLB in a __single__
section and relocate that section!

Cheers,
Dick Johnson
Penguin : Linux version 2.6.15.4 on an i686 machine (5589.54 BogoMips).
Warning : 98.36% of all statistics are fiction.
_


****************************************************************
The information transmitted in this message is confidential and may be privileged. Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited. If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to [email protected] - and destroy all copies of this information, including any attachments, without reading or disclosing them.

Thank you.

2006-02-23 16:59:49

by Benjamin LaHaise

[permalink] [raw]
Subject: Re: Patch to reorder functions in the vmlinux to a defined order

On Thu, Feb 23, 2006 at 08:48:43AM -0800, Linus Torvalds wrote:
> For example, on x86(-64), memcpy() is mostly inlined for the interesting
> cases. That's not always so. Other architectures will have things like the
> page copying and clearing as _the_ hottest functions. Same goes for
> architecture-specific things like context switching etc, that have
> different names on different architectures.

On x86-64 the way gcc inlines memcpy() is rather broken, too. If the
kernel is compiled with -Os instead of -O2, gcc seems to always use
rep ; movs or rep ; stos, which is substantially slower (factor of 10
or more for some sizes -- a few parallel issued pipelined instructions
vs tieing up the entire pipeline until the size of the move is known and
dispatched) for small size data structures. Each instance fixed was
worth a few percent on the P4 when looking at lmbench's af_unix component.

-ben
--
"Ladies and gentlemen, I'm sorry to interrupt, but the police are here
and they've asked us to stop the party." Don't Email: <[email protected]>.

2006-02-23 17:09:11

by Linus Torvalds

[permalink] [raw]
Subject: Re: Patch to reorder functions in the vmlinux to a defined order



On Thu, 23 Feb 2006, Arjan van de Ven wrote:
> >
> > I think you would first need to move the code first for that. Currently it starts
> > at 1MB, which means 1MB is already wasted of the aligned 2MB TLB entry.
> >
> > I wouldn't have a problem with moving the 64bit kernel to 2MB though.
>
> that was easy since it's a Config entry already ;)

Btw, the "low TLB entry" for the direct-mapped case can't be used as a
hugetlb page anyway, due to the MMU splitting it up due to the special
MTRR regions, if I recall correctly.

So this is probably a bigger performance win than just the difference
between using one or two TLB entries.

The same should be true on x86, btw. Where we should use a physical start
address of 4MB for best performance.

Does anybody want to run benchmarks? (Totally untested, may not boot,
might physically accost your pets for all I know).

Linus

---
diff --git a/arch/i386/Kconfig b/arch/i386/Kconfig
index 0afec85..d2b1df8 100644
--- a/arch/i386/Kconfig
+++ b/arch/i386/Kconfig
@@ -715,7 +715,7 @@ config PHYSICAL_START
hex "Physical address where the kernel is loaded" if (EMBEDDED || CRASH_DUMP)

default "0x1000000" if CRASH_DUMP
- default "0x100000"
+ default "0x400000"
help
This gives the physical address where the kernel is loaded. Normally
for regular kernels this value is 0x100000 (1MB). But in the case

2006-02-23 17:20:57

by Andi Kleen

[permalink] [raw]
Subject: Re: Patch to reorder functions in the vmlinux to a defined order

On Thursday 23 February 2006 18:08, Linus Torvalds wrote:
>
> On Thu, 23 Feb 2006, Arjan van de Ven wrote:
> > >
> > > I think you would first need to move the code first for that. Currently it starts
> > > at 1MB, which means 1MB is already wasted of the aligned 2MB TLB entry.
> > >
> > > I wouldn't have a problem with moving the 64bit kernel to 2MB though.
> >
> > that was easy since it's a Config entry already ;)
>
> Btw, the "low TLB entry" for the direct-mapped case can't be used as a
> hugetlb page anyway, due to the MMU splitting it up due to the special
> MTRR regions, if I recall correctly.

I was to suggest the same thing originally, but on several boxes I checked
there weren't any special MTRRs < 1MB, only in the PCI memory hole
<4GB. I suspect there isn't just any interesting hardware in 640K anymore.

BTW I have been also pondering some time to really trust e820 and not
forcibly reserve 640K-1MB on 64bit. That code was inherited from i386,
but probably never made too much sense

[I remember actually taking it out very early, but then putting
it back when I was hunting some insidious unrelated bug. But it wasn't that]

Perhaps that would be a good idea to ignore that newer i386 systems too
(newer defined as having DMI BIOS dates >2000 or so)

-Andi

2006-02-23 17:30:46

by Alan

[permalink] [raw]
Subject: Re: Patch to reorder functions in the vmlinux to a defined order

On Iau, 2006-02-23 at 18:20 +0100, Andi Kleen wrote:
> BTW I have been also pondering some time to really trust e820 and not
> forcibly reserve 640K-1MB on 64bit. That code was inherited from i386,
> but probably never made too much sense

Depends if you want your boot video stuff to work, and vga space, and
also how the ISA hole is used, some chipsets seem to use the RAM that
would be there remapped elsewhere as SMM ram.

Alan

2006-02-23 17:32:14

by Zwane Mwaikambo

[permalink] [raw]
Subject: Re: Patch to reorder functions in the vmlinux to a defined order

On Thu, 23 Feb 2006, Arjan van de Ven wrote:

> This patch puts the infrastructure in place to allow for a reordering of
> functions based inside the vmlinux. The general idea is that it is possible
> to put all "common" functions into the first 2Mb of the code, so that they
> are covered by one TLB entry. This as opposed to the current situation where
> a typical vmlinux covers about 3.5Mb (on x86-64) and thus 2 TLB entries.
> (This patch depends on the previous patch to pin head.S as first in the order)

Hello Arjan,
Assuming that functions defined in an object file are related and
hence benefit from cache spatial locality, doesn't this affect this
greatly? It would seem that with regards to the kernel image on x86, (2MB)
TLB usage isn't as scarce a resource as icache.

2006-02-23 17:44:40

by Linus Torvalds

[permalink] [raw]
Subject: Re: Patch to reorder functions in the vmlinux to a defined order



On Thu, 23 Feb 2006, Andi Kleen wrote:
>
> I was to suggest the same thing originally, but on several boxes I checked
> there weren't any special MTRRs < 1MB, only in the PCI memory hole
> <4GB. I suspect there isn't just any interesting hardware in 640K anymore.

I wasn't talking about the regular MTRR's, but about the magic one: the
"Fixed Range MTRRs" that only map the low 1MB.

I'm pretty sure that they are still used by the BIOS to set up the
640k->1M window.

Linus

2006-02-23 18:00:25

by Arjan van de Ven

[permalink] [raw]
Subject: Re: Patch to reorder functions in the vmlinux to a defined order

Zwane Mwaikambo wrote:
> On Thu, 23 Feb 2006, Arjan van de Ven wrote:
>
>> This patch puts the infrastructure in place to allow for a reordering of
>> functions based inside the vmlinux. The general idea is that it is possible
>> to put all "common" functions into the first 2Mb of the code, so that they
>> are covered by one TLB entry. This as opposed to the current situation where
>> a typical vmlinux covers about 3.5Mb (on x86-64) and thus 2 TLB entries.
>> (This patch depends on the previous patch to pin head.S as first in the order)
>
> Hello Arjan,
> Assuming that functions defined in an object file are related and
> hence benefit from cache spatial locality, doesn't this affect this
> greatly? It would seem that with regards to the kernel image on x86, (2MB)
> TLB usage isn't as scarce a resource as icache.

this is probably a mixed blessing; right now frequent and non-frequent
code are highly intermixed, so even in the current situation the icache
isn't optimally used.

So what you sort of want is a thing better than pure "sort", a sort that
keeps existing order *within the hot functions*, but move the "cold"
ones out. That is thankfully independent of the infrastructure; I'll
keep that in mind when making the next version of the order list, it's a
good idea.

2006-02-23 18:02:13

by Arjan van de Ven

[permalink] [raw]
Subject: Re: Patch to reorder functions in the vmlinux to a defined order

Linus Torvalds wrote:
>
> On Thu, 23 Feb 2006, Arjan van de Ven wrote:
>> I think that to get to a better list we need to invite people to submit
>> their own profiles, and somehow add those all up and base the final list on
>> that. I'm willing to do that effort if this is ends up being the prefered
>> approach. Such an effort probably needs to be repeated like once a year or
>> so to adopt to the changing nature of the kernel.
>
> I suspect we need architecture-specific profiles.
>
> For example, on x86(-64), memcpy() is mostly inlined for the interesting
> cases. That's not always so. Other architectures will have things like the
> page copying and clearing as _the_ hottest functions. Same goes for
> architecture-specific things like context switching etc, that have
> different names on different architectures.
>
> So putting the profile data in scripts/ doesn't sound very good.

ok fair enough; that's easy to fix.


> That said, this certainly seems simple enough. I'd like to hear about
> actual performance improvements with it before I'd apply anything like
> this.

the results were sort of inconclusive (eg some wins, but some losses,
but mostly in the noise) in the "large" run done by the perf guys, so
I'm hoping to get another slot in testing soonish.

>
> Also, since it's quite possible that being dense in the I$ is more of an
> issue than being dense in the TLB (especially since almost everybody has
> super-pages for kernel TLB entries and thus uses just a single entry - or
> maybe a couple - for the kernel), it would probably make sense to try to
> take calling patterns into account some way.

or keep the existing order for a "hot set", but move all the cold ones
out. That way it'll at least not be worse than today

2006-02-23 18:28:11

by Andi Kleen

[permalink] [raw]
Subject: Re: Patch to reorder functions in the vmlinux to a defined order

On Thursday 23 February 2006 18:34, Alan Cox wrote:
> On Iau, 2006-02-23 at 18:20 +0100, Andi Kleen wrote:
> > BTW I have been also pondering some time to really trust e820 and not
> > forcibly reserve 640K-1MB on 64bit. That code was inherited from i386,
> > but probably never made too much sense
>
> Depends if you want your boot video stuff to work, and vga space, and
> also how the ISA hole is used, some chipsets seem to use the RAM that
> would be there remapped elsewhere as SMM ram.

e820 should report that.

I would hope that e820 is correct on modern systems.

Ok it would be a test - if it causes too much collational damage it could be undone.

-Andi

2006-02-23 18:28:10

by Andi Kleen

[permalink] [raw]
Subject: Re: Patch to reorder functions in the vmlinux to a defined order

On Thursday 23 February 2006 18:44, Linus Torvalds wrote:
>
> On Thu, 23 Feb 2006, Andi Kleen wrote:
> >
> > I was to suggest the same thing originally, but on several boxes I checked
> > there weren't any special MTRRs < 1MB, only in the PCI memory hole
> > <4GB. I suspect there isn't just any interesting hardware in 640K anymore.
>
> I wasn't talking about the regular MTRR's, but about the magic one: the
> "Fixed Range MTRRs" that only map the low 1MB.
>
> I'm pretty sure that they are still used by the BIOS to set up the
> 640k->1M window.

Ah you're right i forgot that one.

-Andi

2006-02-23 19:04:12

by linux-os (Dick Johnson)

[permalink] [raw]
Subject: Re: Patch to reorder functions in the vmlinux to a defined order


On Thu, 23 Feb 2006, Linus Torvalds wrote:

>
>
> On Thu, 23 Feb 2006, Arjan van de Ven wrote:
>>>
>>> I think you would first need to move the code first for that. Currently it starts
>>> at 1MB, which means 1MB is already wasted of the aligned 2MB TLB entry.
>>>
>>> I wouldn't have a problem with moving the 64bit kernel to 2MB though.
>>
>> that was easy since it's a Config entry already ;)
>
> Btw, the "low TLB entry" for the direct-mapped case can't be used as a
> hugetlb page anyway, due to the MMU splitting it up due to the special
> MTRR regions, if I recall correctly.
>
> So this is probably a bigger performance win than just the difference
> between using one or two TLB entries.
>
> The same should be true on x86, btw. Where we should use a physical start
> address of 4MB for best performance.
>
> Does anybody want to run benchmarks? (Totally untested, may not boot,
> might physically accost your pets for all I know).
>
> Linus

I just reconfigured and rebuilt linux-2.6.15.4 to put PHYSICAL_START
at 0x00400000, unconditionally and it booted fine and is working so
a 'boot' shouldn't be a problem.


Cheers,
Dick Johnson
Penguin : Linux version 2.6.15.4 on an i686 machine (5589.54 BogoMips).
Warning : 98.36% of all statistics are fiction.
_


****************************************************************
The information transmitted in this message is confidential and may be privileged. Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited. If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to [email protected] - and destroy all copies of this information, including any attachments, without reading or disclosing them.

Thank you.

2006-02-23 19:22:44

by Rene Herman

[permalink] [raw]
Subject: Re: Patch to reorder functions in the vmlinux to a defined order

Linus Torvalds wrote:

> The same should be true on x86, btw. Where we should use a physical start
> address of 4MB for best performance.

Does 16MB still work? Gets the kernel out of the old ZONE_DMA. I suppose
not many people are really using that anyway anymore these days, but if
no downsides maybe?

Also, did the kernel still boot on a 4M machine, and would it still do
so with the change to 4M as posted? 2.4 used to boot fine with 4M. Not
certain anymore if I ever tested that with 2.6 (and can't right now).

Rene.

2006-02-23 19:31:24

by Andi Kleen

[permalink] [raw]
Subject: Re: Patch to reorder functions in the vmlinux to a defined order

On Thursday 23 February 2006 20:23, Rene Herman wrote:
> Linus Torvalds wrote:
>
> > The same should be true on x86, btw. Where we should use a physical start
> > address of 4MB for best performance.
>
> Does 16MB still work? Gets the kernel out of the old ZONE_DMA. I suppose
> not many people are really using that anyway anymore these days, but if
> no downsides maybe?

That would prevent booting on < 18MB or so
>
> Also, did the kernel still boot on a 4M machine, and would it still do
> so with the change to 4M as posted? 2.4 used to boot fine with 4M. Not
> certain anymore if I ever tested that with 2.6 (and can't right now).

It wouldn't without additional changes.

-Andi

2006-02-23 19:31:10

by Alan

[permalink] [raw]
Subject: Re: Patch to reorder functions in the vmlinux to a defined order

On Iau, 2006-02-23 at 20:23 +0100, Rene Herman wrote:
> Linus Torvalds wrote:
>
> > The same should be true on x86, btw. Where we should use a physical start
> > address of 4MB for best performance.
>
> Does 16MB still work? Gets the kernel out of the old ZONE_DMA. I suppose
> not many people are really using that anyway anymore these days, but if
> no downsides maybe?

Certainly the PAE kernel might as well do that and the AMD64 if it
doesn't already. There are complications however getting above 16MB
because 16bit protected mode (and maybe the BIOS helpers - I need to
check that) can't hit it.

We also used to have people DMAing into static kernel buffers in older
days but hopefully that habit is now dead and gone because modules
sorted most of it out.


2006-02-23 19:33:04

by Linus Torvalds

[permalink] [raw]
Subject: Re: Patch to reorder functions in the vmlinux to a defined order



On Thu, 23 Feb 2006, linux-os (Dick Johnson) wrote:
> >
> > Does anybody want to run benchmarks? (Totally untested, may not boot,
> > might physically accost your pets for all I know).
> >
> > Linus
>
> I just reconfigured and rebuilt linux-2.6.15.4 to put PHYSICAL_START
> at 0x00400000, unconditionally and it booted fine and is working so
> a 'boot' shouldn't be a problem.

I ended up doing even more.

For me, running lmbench with this, it seems to improve some things by up
to 20% (pipe bandwidth and latency, small file delete), some other things
by 10% (larger file delete), and others not at all.

Still, that 20% is _huge_.

HOWEVER. I didn't compare very strictly. I should have done many more runs
(I only did three), and more importantly, I should have compared the exact
same kernel (I compared the new results against a kernel that was a couple
of weeks old, so there were other differences). So it's a bit suspect.
Finally, it might depend on the core a lot, and other cores might not get
the same results.

So somebody should do a much better test. I'm too lazy.

Linus

2006-02-23 19:35:26

by Linus Torvalds

[permalink] [raw]
Subject: Re: Patch to reorder functions in the vmlinux to a defined order



On Thu, 23 Feb 2006, Rene Herman wrote:
>
> Also, did the kernel still boot on a 4M machine, and would it still do so with
> the change to 4M as posted? 2.4 used to boot fine with 4M. Not certain anymore
> if I ever tested that with 2.6 (and can't right now).

If you want to boot a 4MB machine with the suggested patch, you'd have to
enable CONFIG_EMBEDDED (something you'd likely want to do anyway, for a 4M
machine), and turn the physical start address back down to 1MB.

That's one reason I didn't make it 16MB. A 4MB machine is pretty damn
embedded these days (you'd want to enable EMBEDDED just to turn off some
other things that make the kernel bigger), but I can imagine that real
people run Linux/x86 in 16MB as long as they don't run X.

Linus

2006-02-23 19:44:20

by Arjan van de Ven

[permalink] [raw]
Subject: Re: Patch to reorder functions in the vmlinux to a defined order

\
> That's one reason I didn't make it 16MB. A 4MB machine is pretty damn
> embedded these days (you'd want to enable EMBEDDED just to turn off some
> other things that make the kernel bigger), but I can imagine that real
> people run Linux/x86 in 16MB as long as they don't run X.

for PAE it might make sense to just bump it to 16... but then again..
DMA zone pressure in 2.6 is almost gone anyway

2006-02-23 19:47:39

by Rene Herman

[permalink] [raw]
Subject: Re: Patch to reorder functions in the vmlinux to a defined order

Alan Cox wrote:

> On Iau, 2006-02-23 at 20:23 +0100, Rene Herman wrote:

>> Does 16MB still work? Gets the kernel out of the old ZONE_DMA. I suppose
>> not many people are really using that anyway anymore these days, but if
>> no downsides maybe?
>
> Certainly the PAE kernel might as well do that and the AMD64 if it
> doesn't already. There are complications however getting above 16MB
> because 16bit protected mode (and maybe the BIOS helpers - I need to
> check that) can't hit it.

INT 15/AH=0x87 (move from low to high) on a 386+ should work, according
to the documentation I have... Is PM16 used anywhere?

> We also used to have people DMAing into static kernel buffers in older
> days but hopefully that habit is now dead and gone because modules
> sorted most of it out.

Good method to flush out any possible remaining users :-)

Rene.

2006-02-23 20:08:33

by Andy Whitcroft

[permalink] [raw]
Subject: Re: Patch to reorder functions in the vmlinux to a defined order

Linus Torvalds wrote:

> Does anybody want to run benchmarks? (Totally untested, may not boot,
> might physically accost your pets for all I know).

Will throw this into the nightly tests and see what pops out.

-apw

2006-02-23 20:12:57

by Rene Herman

[permalink] [raw]
Subject: Re: Patch to reorder functions in the vmlinux to a defined order

Linus Torvalds wrote:

> If you want to boot a 4MB machine with the suggested patch, you'd
> have to enable CONFIG_EMBEDDED (something you'd likely want to do
> anyway, for 4M machine), and turn the physical start address back
> down to 1MB.

Okay. I suppose the only other option is to make "physical_start" a
variable passed in by the bootloader so that it could make a runtime
decision? Ie, place us at min(top_of_mem, 4G) if it cared to. I just
grepped for PHYSICAL_START and this didn't look _too_ bad.

I'm out of my league here though -- if I remember correctly from some
reading of the early bootcode I once did, the kernel set up some
temporary tables first to only cover the first few MB? If so, then I
guess it would be a significant change.

Seems a bit cleaner though than just hardcoding the address.

> That's one reason I didn't make it 16MB. A 4MB machine is pretty damn
> embedded these days (you'd want to enable EMBEDDED just to turn off
> some other things that make the kernel bigger), but I can imagine
> that real people run Linux/x86 in 16MB as long as they don't run X.

My 386 is happy with its current 16M (it can't cache all of the 32M I
can physically put in), used to be happy with 8M, and used to boot with
4M... ofcourse, although it's not very embedded (you should see it) it's
also not very "real" in that sense ;-)

Love the machine to death, though...

Rene.

2006-02-23 20:26:55

by Dave Jones

[permalink] [raw]
Subject: Re: Patch to reorder functions in the vmlinux to a defined order

On Thu, Feb 23, 2006 at 09:13:24PM +0100, Rene Herman wrote:
> Linus Torvalds wrote:
>
> >If you want to boot a 4MB machine with the suggested patch, you'd
> >have to enable CONFIG_EMBEDDED (something you'd likely want to do
> >anyway, for 4M machine), and turn the physical start address back
> >down to 1MB.
>
> Okay. I suppose the only other option is to make "physical_start" a
> variable passed in by the bootloader so that it could make a runtime
> decision? Ie, place us at min(top_of_mem, 4G) if it cared to. I just
> grepped for PHYSICAL_START and this didn't look _too_ bad.
>
> I'm out of my league here though -- if I remember correctly from some
> reading of the early bootcode I once did, the kernel set up some
> temporary tables first to only cover the first few MB? If so, then I
> guess it would be a significant change.
>
> Seems a bit cleaner though than just hardcoding the address.

the kdump people were looking at making the kernel runtime relocatable
at one point, which with my distro-vendor hat on, would be useful
as it'd mean we could use the same kernel image for normal boot, and
also for the 'kdump kernel' (Right now, we ship another set of
kernels for each arch with a different PHYSICAL_START).
(You wouldn't believe how much grief we get from the installer folks
for adding another set of kernel images to the ISOs).

I think that work stalled a while back though.

Dave

2006-02-23 23:20:11

by Linus Torvalds

[permalink] [raw]
Subject: Re: Patch to reorder functions in the vmlinux to a defined order



On Thu, 23 Feb 2006, Rene Herman wrote:
>
> Okay. I suppose the only other option is to make "physical_start" a variable
> passed in by the bootloader so that it could make a runtime decision? Ie,
> place us at min(top_of_mem, 4G) if it cared to. I just grepped for
> PHYSICAL_START and this didn't look _too_ bad.

No can do. You'd have to make the kernel relocatable, and do load-time
fixups. Very invasive.

It's certainly _possible_, but it's a whole new stage in the boot, one
that we've never done before.

Linus

2006-02-23 23:53:07

by Rene Herman

[permalink] [raw]
Subject: Re: Patch to reorder functions in the vmlinux to a defined order

Linus Torvalds wrote:

> On Thu, 23 Feb 2006, Rene Herman wrote:

>> Okay. I suppose the only other option is to make "physical_start" a variable
>> passed in by the bootloader so that it could make a runtime decision? Ie,
>> place us at min(top_of_mem, 4G) if it cared to. I just grepped for
>> PHYSICAL_START and this didn't look _too_ bad.
>
> No can do. You'd have to make the kernel relocatable, and do load-time
> fixups. Very invasive.

Yes, that wasn't too smart. I believe in principe most of it _could_ be
done via some pagetable trickery though, with the kernel still at a
fixed virtual address?

Rene.

2006-02-24 01:38:34

by Martin Bligh

[permalink] [raw]
Subject: Re: Patch to reorder functions in the vmlinux to a defined order

Linus Torvalds wrote:
>
> On Thu, 23 Feb 2006, Rene Herman wrote:
>
>>Also, did the kernel still boot on a 4M machine, and would it still do so with
>>the change to 4M as posted? 2.4 used to boot fine with 4M. Not certain anymore
>>if I ever tested that with 2.6 (and can't right now).
>
>
> If you want to boot a 4MB machine with the suggested patch, you'd have to
> enable CONFIG_EMBEDDED (something you'd likely want to do anyway, for a 4M
> machine), and turn the physical start address back down to 1MB.
>
> That's one reason I didn't make it 16MB. A 4MB machine is pretty damn
> embedded these days (you'd want to enable EMBEDDED just to turn off some
> other things that make the kernel bigger), but I can imagine that real
> people run Linux/x86 in 16MB as long as they don't run X.

ISTR from a long time ago, bootstrapping NUMA-Q, that in early boot we
only have the first 8MB mapped. Might have changed, and is probably
easily fixable, but ...

M.

Subject: Re: Patch to reorder functions in the vmlinux to a defined order

On Thu, 2006-02-23 at 15:26 -0500, Dave Jones wrote:
> On Thu, Feb 23, 2006 at 09:13:24PM +0100, Rene Herman wrote:
> > Linus Torvalds wrote:
> >
> > >If you want to boot a 4MB machine with the suggested patch, you'd
> > >have to enable CONFIG_EMBEDDED (something you'd likely want to do
> > >anyway, for 4M machine), and turn the physical start address back
> > >down to 1MB.
> >
> > Okay. I suppose the only other option is to make "physical_start" a
> > variable passed in by the bootloader so that it could make a runtime
> > decision? Ie, place us at min(top_of_mem, 4G) if it cared to. I just
> > grepped for PHYSICAL_START and this didn't look _too_ bad.
> >
> > I'm out of my league here though -- if I remember correctly from some
> > reading of the early bootcode I once did, the kernel set up some
> > temporary tables first to only cover the first few MB? If so, then I
> > guess it would be a significant change.
> >
> > Seems a bit cleaner though than just hardcoding the address.
>
> the kdump people were looking at making the kernel runtime relocatable
> at one point, which with my distro-vendor hat on, would be useful
> as it'd mean we could use the same kernel image for normal boot, and
> also for the 'kdump kernel'
The mkdump team has accomplished this ...

> (Right now, we ship another set of
> kernels for each arch with a different PHYSICAL_START).
... so that we do not need to hard-code PHYSICAL_START. The dump capture
kernel is able to run from any memory address the host kernel reserves
for it. The are some limitations though:

- i386: the second kernel has to be loaded in low memory
- x86_64: the second kernel has to be loaded below 1GB (we are working
to move this limit to 4GB)

> (You wouldn't believe how much grief we get from the installer folks
> for adding another set of kernel images to the ISOs).
>
> I think that work stalled a while back though.

The mkdump team has been using runtime relocatable kernels for two years
and we are currently working on porting this functionality to kdump. I
was wondering if it would be accepted mainstream.

Regards,

Fernando

2006-02-24 02:49:14

by Andi Kleen

[permalink] [raw]
Subject: Re: Patch to reorder functions in the vmlinux to a defined order

On Friday 24 February 2006 03:44, Fernando Luis Vazquez Cao wrote:

> The mkdump team has been using runtime relocatable kernels for two years
> and we are currently working on porting this functionality to kdump. I
> was wondering if it would be accepted mainstream.

The question cannot be answered without a patch to look at. Just post
it once it works.

-Andi

2006-02-24 12:43:25

by linux-os (Dick Johnson)

[permalink] [raw]
Subject: Re: Patch to reorder functions in the vmlinux to a defined order


On Thu, 23 Feb 2006, Linus Torvalds wrote:

>
> On Thu, 23 Feb 2006, linux-os (Dick Johnson) wrote:
>>>
>>> Does anybody want to run benchmarks? (Totally untested, may not boot,
>>> might physically accost your pets for all I know).
>>>
>>> Linus
>>
>> I just reconfigured and rebuilt linux-2.6.15.4 to put PHYSICAL_START
>> at 0x00400000, unconditionally and it booted fine and is working so
>> a 'boot' shouldn't be a problem.
>
> I ended up doing even more.
>
> For me, running lmbench with this, it seems to improve some things by up
> to 20% (pipe bandwidth and latency, small file delete), some other things
> by 10% (larger file delete), and others not at all.
>
> Still, that 20% is _huge_.
>
> HOWEVER. I didn't compare very strictly. I should have done many more runs
> (I only did three), and more importantly, I should have compared the exact
> same kernel (I compared the new results against a kernel that was a couple
> of weeks old, so there were other differences). So it's a bit suspect.
> Finally, it might depend on the core a lot, and other cores might not get
> the same results.
>
> So somebody should do a much better test. I'm too lazy.
>
> Linus
>


I compiled the kernel with the kernel start address at both
0x00400000 and 0x00100000.

Conditions:
No network attached, machine newly rebooted, no other activity.

Meminfo AFTER the last compile.

MemTotal: 773856 kB
MemFree: 16388 kB
Buffers: 328532 kB
Cached: 39888 kB
SwapCached: 0 kB
Active: 129072 kB
Inactive: 258928 kB
HighTotal: 0 kB
HighFree: 0 kB
LowTotal: 773856 kB
LowFree: 16388 kB
SwapTotal: 907664 kB
SwapFree: 907664 kB
Dirty: 4 kB
Writeback: 0 kB
Mapped: 33924 kB
Slab: 361224 kB
CommitLimit: 1294592 kB
Committed_AS: 29292 kB
PageTables: 736 kB
VmallocTotal: 253652 kB
VmallocUsed: 2708 kB
VmallocChunk: 250684 kB
HugePages_Total: 0
HugePages_Free: 0
Hugepagesize: 4096 kB

CPU Info:

processor : 0
vendor_id : GenuineIntel
cpu family : 15
model : 2
model name : Intel(R) Pentium(R) 4 CPU 2.80GHz
stepping : 7
cpu MHz : 2793.305
cache size : 512 KB
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 2
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe cid xtpr
bogomips : 5589.53

This CPU is supposed to be SMP, and the kernel is compiled SMP, but
I was never able to have the two cores show up. It shouldn't affect
the comparison bench-marks.

Tail end of the log with the start at 0x00400000.

CC sound/usb/snd-usb-audio.mod.o
LD [M] sound/usb/snd-usb-audio.ko
CC sound/usb/snd-usb-lib.mod.o
LD [M] sound/usb/snd-usb-lib.ko
CC sound/usb/usx2y/snd-usb-usx2y.mod.o
LD [M] sound/usb/usx2y/snd-usb-usx2y.ko

real 33m4.832s
user 29m47.359s
sys 3m13.611s


Tail end of the log with the start at 0x00100000.

CC sound/usb/snd-usb-audio.mod.o
LD [M] sound/usb/snd-usb-audio.ko
CC sound/usb/snd-usb-lib.mod.o
LD [M] sound/usb/snd-usb-lib.ko
CC sound/usb/usx2y/snd-usb-usx2y.mod.o
LD [M] sound/usb/usx2y/snd-usb-usx2y.ko

real 33m21.078s
user 29m41.274s
sys 3m13.910s

Conclusion: It doesn't make a damn bit of difference one way or
the other on this machine!

Cheers,
Dick Johnson
Penguin : Linux version 2.6.15.4 on an i686 machine (5589.53 BogoMips).
Warning : 98.36% of all statistics are fiction.
_


****************************************************************
The information transmitted in this message is confidential and may be privileged. Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited. If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to [email protected] - and destroy all copies of this information, including any attachments, without reading or disclosing them.

Thank you.

2006-02-24 13:50:45

by Eric W. Biederman

[permalink] [raw]
Subject: Re: Patch to make the head.S-must-be-first-in-vmlinux order explicit

Andi Kleen <[email protected]> writes:

> On Thursday 23 February 2006 14:57, Arjan van de Ven wrote:
>
>> > (or at least
>> > it shouldn't), but arch/x86_64/boot/compressed/head.S
>> > seems to have the entry address hardcoded. Perhaps you can just change this
>> > to pass in the right address?
>>
>> the issue is that the address will be a link time thing, which means
>> lots of complexity.
>
> bzImage image should be only generated after vmlinux is done
> and then the address should be available with a simple grep in System.map

Andi it is more than that. At least it was last I payed attention.
There are symbols like stext that various things depend on being early,
at least last time I looked. So while it is doable it requires some
careful looking.

Eric

2006-02-24 13:53:58

by Arjan van de Ven

[permalink] [raw]
Subject: Re: Patch to make the head.S-must-be-first-in-vmlinux order explicit

Eric W. Biederman wrote:
> Andi Kleen <[email protected]> writes:
>
>> On Thursday 23 February 2006 14:57, Arjan van de Ven wrote:
>>
>>>> (or at least
>>>> it shouldn't), but arch/x86_64/boot/compressed/head.S
>>>> seems to have the entry address hardcoded. Perhaps you can just change this
>>>> to pass in the right address?
>>> the issue is that the address will be a link time thing, which means
>>> lots of complexity.
>> bzImage image should be only generated after vmlinux is done
>> and then the address should be available with a simple grep in System.map
>
> Andi it is more than that. At least it was last I payed attention.
> There are symbols like stext that various things depend on being early,
> at least last time I looked. So while it is doable it requires some
> careful looking.

_stext and such are very easy. That is actually not a real variable just
a linker script thing, and since the reordering works on the linker
script level that's already taken care of ;-)

I've looked some yesterday at generating this at runtime, and haven't
found a clean enough solution yet (esp one that doesn't break kdump);
I'll keep poking at it for a bit more though....

2006-02-24 14:12:59

by Eric W. Biederman

[permalink] [raw]
Subject: Re: Patch to reorder functions in the vmlinux to a defined order

Linus Torvalds <[email protected]> writes:

> On Thu, 23 Feb 2006, Rene Herman wrote:
>>
>> Okay. I suppose the only other option is to make "physical_start" a variable
>> passed in by the bootloader so that it could make a runtime decision? Ie,
>> place us at min(top_of_mem, 4G) if it cared to. I just grepped for
>> PHYSICAL_START and this didn't look _too_ bad.

Well the way to accomplish that is to just load the kernel there and
have it sort itself out. It would take a rev of the boot protocol
to let the bootloader know it was possible though.

> No can do. You'd have to make the kernel relocatable, and do load-time
> fixups. Very invasive.

Not really. With the linker able to generate the relocations you can
do it outside of most of the kernel where we have the decompressor.

Relocating a kernel is fundamentally an architecture dependent thing,
relocations can't work at all on x86-64 for example because of the narrow
window of virtual addresses it needs to run at.

I only haven't submitted the patches because I was too busy stabilizing
the reboot path last time I had time to be working in this area.

After I get some sleep I will dust off my patches and see how
it goes. x86-64 will probably have regressed but...

> It's certainly _possible_, but it's a whole new stage in the boot, one
> that we've never done before.

It isn't that new. There has been interest in this area from the
people working on the kdump stuff for a long you don't require
options under CONFIG_EMBEDDED to build a kernel for capturing a crash
dump.

CONFIG_PHYSICAL_START was supposed be the simple interim solution
until we could get relocation patches sorted out and merged.

Eric

2006-02-24 14:18:30

by Eric W. Biederman

[permalink] [raw]
Subject: Re: Patch to make the head.S-must-be-first-in-vmlinux order explicit

Arjan van de Ven <[email protected]> writes:

> Eric W. Biederman wrote:
>> Andi Kleen <[email protected]> writes:
>>
>>> On Thursday 23 February 2006 14:57, Arjan van de Ven wrote:
>>>
>>>>> (or at least
>>>>> it shouldn't), but arch/x86_64/boot/compressed/head.S
>>>>> seems to have the entry address hardcoded. Perhaps you can just change this
>>>>> to pass in the right address?
>>>> the issue is that the address will be a link time thing, which means lots of
>>>> complexity.
>>> bzImage image should be only generated after vmlinux is done and then the
>>> address should be available with a simple grep in System.map
>> Andi it is more than that. At least it was last I payed attention.
>> There are symbols like stext that various things depend on being early,
>> at least last time I looked. So while it is doable it requires some
>> careful looking.
>
> _stext and such are very easy. That is actually not a real variable just a
> linker script thing, and since the reordering works on the linker script level
> that's already taken care of ;-)

It is currently a symbol defined in head.S though. Not hard to fix
but the point is that there are a few subtle things.

> I've looked some yesterday at generating this at runtime, and haven't found a
> clean enough solution yet (esp one that doesn't break kdump); I'll keep poking
> at it for a bit more though....

I suspect the easy way to do this is to put a variable with the start location
either at the very start or the very end of the data that gets compressed that
has the address to jump to. Once we uncompressed the data we can lookup
the pointer and jump to it.

Eric

2006-02-24 14:24:21

by Eric W. Biederman

[permalink] [raw]
Subject: Re: Patch to reorder functions in the vmlinux to a defined order

Rene Herman <[email protected]> writes:

> Linus Torvalds wrote:
>
>> On Thu, 23 Feb 2006, Rene Herman wrote:
>
>>> Okay. I suppose the only other option is to make "physical_start" a variable
>>> passed in by the bootloader so that it could make a runtime decision? Ie,
>>> place us at min(top_of_mem, 4G) if it cared to. I just grepped for
>>> PHYSICAL_START and this didn't look _too_ bad.
>> No can do. You'd have to make the kernel relocatable, and do load-time
>> fixups. Very invasive.
>
> Yes, that wasn't too smart. I believe in principe most of it _could_ be done via
> some pagetable trickery though, with the kernel still at a fixed virtual
> address?

The page table trickery is actually the more invasive approach. I believe
for 32 bit kernels the real problem is giving up the identity mapping of
low memory. Short of the moving the kernel to end of the address space
where vmalloc and the fixmaps are now I don't think there is a reasonable chunk
of the address space we can use.

Eric

2006-02-24 14:24:30

by Eric W. Biederman

[permalink] [raw]
Subject: Re: Patch to reorder functions in the vmlinux to a defined order

Rene Herman <[email protected]> writes:

> Linus Torvalds wrote:
>
>> On Thu, 23 Feb 2006, Rene Herman wrote:
>
>>> Okay. I suppose the only other option is to make "physical_start" a variable
>>> passed in by the bootloader so that it could make a runtime decision? Ie,
>>> place us at min(top_of_mem, 4G) if it cared to. I just grepped for
>>> PHYSICAL_START and this didn't look _too_ bad.
>> No can do. You'd have to make the kernel relocatable, and do load-time
>> fixups. Very invasive.
>
> Yes, that wasn't too smart. I believe in principe most of it _could_ be done via
> some pagetable trickery though, with the kernel still at a fixed virtual
> address?

The page table trickery is actually the more invasive approach. I believe
for 32 bit kernels the real problem is giving up the identity mapping of
low memory. Short of the moving the kernel to end of the address space
where vmalloc and the fixmaps are now I don't think there is a reasonable chunk
of the address space we can use.

Eric

2006-02-24 14:33:11

by Andi Kleen

[permalink] [raw]
Subject: Re: Patch to make the head.S-must-be-first-in-vmlinux order explicit

On Friday 24 February 2006 14:53, Arjan van de Ven wrote:

> I've looked some yesterday at generating this at runtime, and haven't
> found a clean enough solution yet (esp one that doesn't break kdump);
> I'll keep poking at it for a bit more though....


Ok if it's too complicated we can force it first.

-Andi

2006-02-24 14:44:28

by Theodore Ts'o

[permalink] [raw]
Subject: Re: Patch to reorder functions in the vmlinux to a defined order

On Fri, Feb 24, 2006 at 11:44:15AM +0900, Fernando Luis Vazquez Cao wrote:
>
> The mkdump team has been using runtime relocatable kernels for two years
> and we are currently working on porting this functionality to kdump. I
> was wondering if it would be accepted mainstream.

What's the overhead? (In code size, complexity, performance, etc.?)

- Ted

2006-02-24 15:30:22

by Rene Herman

[permalink] [raw]
Subject: Re: Patch to reorder functions in the vmlinux to a defined order

Eric W. Biederman wrote:

> The page table trickery is actually the more invasive approach. I
> believe for 32 bit kernels the real problem is giving up the identity
> mapping of low memory.

Yes, you probably don't want to have to specialcase anything there.

> Short of the moving the kernel to end of the address space where
> vmalloc and the fixmaps are now I don't think there is a reasonable
> chunk of the address space we can use.

To my handwaving ears end of the address space sounds very good though.
Is there currently any pressure on VMALLOC_RESERVE (128M)? Teaching the
linker appears to be a matter of changing __KERNEL_START. That leaves
actually mapping ourselves there, and... more invasiveness?

I saw you say you already have some actual relocating patches though?

Rene.

2006-02-24 15:56:51

by Eric W. Biederman

[permalink] [raw]
Subject: Re: Patch to reorder functions in the vmlinux to a defined order

Rene Herman <[email protected]> writes:

> Eric W. Biederman wrote:
>
>> The page table trickery is actually the more invasive approach. I
>> believe for 32 bit kernels the real problem is giving up the identity
>> mapping of low memory.
>
> Yes, you probably don't want to have to specialcase anything there.
>
>> Short of the moving the kernel to end of the address space where
>> vmalloc and the fixmaps are now I don't think there is a reasonable
>> chunk of the address space we can use.
>
> To my handwaving ears end of the address space sounds very good though. Is there
> currently any pressure on VMALLOC_RESERVE (128M)? Teaching the linker appears to
> be a matter of changing __KERNEL_START. That leaves actually mapping ourselves
> there, and... more invasiveness?

__pa stops working on kernel addresses.

> I saw you say you already have some actual relocating patches though?

Yes. Will post them later today, after I get them rebased against a recent
kernel.

Eric

2006-02-24 16:48:47

by Andi Kleen

[permalink] [raw]
Subject: Re: Patch to reorder functions in the vmlinux to a defined order

On Friday 24 February 2006 16:55, Eric W. Biederman wrote:
> there, and... more invasiveness?
>
> __pa stops working on kernel addresses.

x86-64 always had this problem and it's not very hard to handle with a simple ?:

-Andi

2006-02-24 17:27:12

by Linus Torvalds

[permalink] [raw]
Subject: Re: Patch to reorder functions in the vmlinux to a defined order



On Fri, 24 Feb 2006, Eric W. Biederman wrote:
>
> > To my handwaving ears end of the address space sounds very good though. Is there
> > currently any pressure on VMALLOC_RESERVE (128M)? Teaching the linker appears to
> > be a matter of changing __KERNEL_START. That leaves actually mapping ourselves
> > there, and... more invasiveness?
>
> __pa stops working on kernel addresses.

That's not the issue.

The real issue is the _physical_ address. Nothing else matters.

If the TLB splitting on the fixed MTRRs is an issue, it depends entirely
on what physical address the kernel resides in, and the virtual address is
totally inconsequential.

So playing games with virtual mapping has absolutely no upsides, and it
definitely has downsides.

Linus

2006-02-24 17:56:39

by Rene Herman

[permalink] [raw]
Subject: Re: Patch to reorder functions in the vmlinux to a defined order

Linus Torvalds wrote:

> The real issue is the _physical_ address. Nothing else matters.
>
> If the TLB splitting on the fixed MTRRs is an issue, it depends entirely
> on what physical address the kernel resides in, and the virtual address is
> totally inconsequential.
>
> So playing games with virtual mapping has absolutely no upsides, and it
> definitely has downsides.

The notion was that having a fixed virtual mapping of the kernel would
allow it to be loaded anywhere physically without needing to do actual
address fixups. The bootloader could then for example at runtime decide
to load the kernel at 16MB if the machine had enough memory available,
to free up ZONE_DMA. Or not do that if running on a <= 16MB machine.

Or the kdump "host" kernel would make that decission, as it seems the
want is shared with them. Eric Biederman said that fixups aren't that
bad though...

Rene.

2006-02-24 18:12:46

by Linus Torvalds

[permalink] [raw]
Subject: Re: Patch to reorder functions in the vmlinux to a defined order



On Fri, 24 Feb 2006, Rene Herman wrote:
>
> The notion was that having a fixed virtual mapping of the kernel would allow
> it to be loaded anywhere physically without needing to do actual address
> fixups.

Even that doesn't much help. You'd still need to fix up the actual
addresses.

Why? The virtual remapping is limited to 4MB chunks in order to be able to
remap using large pages (2MB in PAE mode). At which point there is no
advantage: you might as well just hardcode the default address to 4MB like
my trivial one-liner did (with an option for EMBEDDED people to link it
lower).

So if the point is that we want to use the same binary for both machines
with less than 4M and for bigger machines, you can't remap the kernel,
unless you start using individual pages, at which point you've destroyed
the biggest reason for doing this in the first place - since your TLB
behaviour will suck.

Linus

2006-02-24 20:39:27

by Eric W. Biederman

[permalink] [raw]
Subject: Re: Patch to reorder functions in the vmlinux to a defined order

Andi Kleen <[email protected]> writes:

> On Friday 24 February 2006 16:55, Eric W. Biederman wrote:
>> there, and... more invasiveness?
>>
>> __pa stops working on kernel addresses.
>
> x86-64 always had this problem and it's not very hard to handle with a simple ?:

It has been several months but yes most of the pieces are simple.
Although you do loose the opportunities for several micro-optimizations,
that way. The point was simply that working with relocations is even
less intrusive. The changes stop at kernel/head.S if they even get
that far. Plus the proof that you have not pessimized things is
trivial, because nothing has changed.

The fact that your kernel virtual addresses can be at different
2MB/4MB aligned boundaries is a downside, as is the fact that your
bzImage becomes 5-10% larger because of all of the relocations.

Eric

2006-02-24 22:19:22

by Tony Luck

[permalink] [raw]
Subject: Re: Patch to reorder functions in the vmlinux to a defined order

On 2/23/06, Arjan van de Ven <[email protected]> wrote:
> As per previous discussions, Linus said he wanted a "static" list for this,
> eg a list provided by the kernel tarbal, so that most people have the same
> ordering at least. A script is provided to create this list based on
> readprofile(1) output. The included list is provisional, and entirely biased
> on my own testbox and me running a few kernel compiles and some other
> things.
>
> I think that to get to a better list we need to invite people to submit
> their own profiles, and somehow add those all up and base the final list on
> that.

1) How will this work in the face of CONFIG options that change the
list of symbols present in your kernel? E.g. my hot oprofile list
might well contain a bunch of symbols from my NIC driver and whatever
filesystem I'm pounding on.

2) If you add enough lists from enough people, perhaps you'll get enough
coverage of the kernel with all their different workloads, that you'll have
too much to fit into the 2M page.

-Tony (Just joining in this thread for fun, ia64 pins all kernel text with a
single mapping, so we don't have any TLB misses at all :)

2006-02-24 22:21:42

by Arjan van de Ven

[permalink] [raw]
Subject: Re: Patch to reorder functions in the vmlinux to a defined order

Tony Luck wrote:
> On 2/23/06, Arjan van de Ven <[email protected]> wrote:
>> As per previous discussions, Linus said he wanted a "static" list for this,
>> eg a list provided by the kernel tarbal, so that most people have the same
>> ordering at least. A script is provided to create this list based on
>> readprofile(1) output. The included list is provisional, and entirely biased
>> on my own testbox and me running a few kernel compiles and some other
>> things.
>>
>> I think that to get to a better list we need to invite people to submit
>> their own profiles, and somehow add those all up and base the final list on
>> that.
>
> 1) How will this work in the face of CONFIG options that change the
> list of symbols present in your kernel? E.g. my hot oprofile list
> might well contain a bunch of symbols from my NIC driver and whatever
> filesystem I'm pounding on.

that is fine; symbols that aren't actually present just are ignored by
the linker in this case

>
> 2) If you add enough lists from enough people, perhaps you'll get enough
> coverage of the kernel with all their different workloads, that you'll have
> too much to fit into the 2M page.

I am more optimistic; the total kernel size in "distro" configuration is
about 3.5Mb. I would find it hard to believe that more than half of that
is "hot" code even in a "many people send their profiles" setup.

2006-02-25 02:11:55

by folkert

[permalink] [raw]
Subject: Re: Patch to reorder functions in the vmlinux to a defined order

What about shuffeling the pages at runtime? Or are cachelines wired to
physical pages?

If not: group pages (even system-wide?) which are used most frequented.
Maybe with help from a userspace tool?


Folkert van Heusden

--
iPod winnen? --> http://keetweej.vanheusden.com/redir.php?id=62
--------------------------------------------------------------------
Phone: +31-6-41278122, PGP-key: 1F28D8AE, http://www.vanheusden.com

2006-02-25 08:32:13

by Arjan van de Ven

[permalink] [raw]
Subject: Re: Patch to reorder functions in the vmlinux to a defined order

On Sat, 2006-02-25 at 03:11 +0100, Folkert van Heusden wrote:
> What about shuffeling the pages at runtime? Or are cachelines wired to
> physical pages?

remember that kernel pages are 2Mb in size, not 4Kb.
That makes it rather highly impractical ;)

(even 4Kb has many practical issues since most functions are smaller
than 4Kb by far)

2006-03-07 23:36:20

by H. Peter Anvin

[permalink] [raw]
Subject: Re: Patch to reorder functions in the vmlinux to a defined order

Followup to: <[email protected]>
By author: Rene Herman <[email protected]>
In newsgroup: linux.dev.kernel
>
> Linus Torvalds wrote:
>
> > The real issue is the _physical_ address. Nothing else matters.
> >
> > If the TLB splitting on the fixed MTRRs is an issue, it depends entirely
> > on what physical address the kernel resides in, and the virtual address is
> > totally inconsequential.
> >
> > So playing games with virtual mapping has absolutely no upsides, and it
> > definitely has downsides.
>
> The notion was that having a fixed virtual mapping of the kernel would
> allow it to be loaded anywhere physically without needing to do actual
> address fixups. The bootloader could then for example at runtime decide
> to load the kernel at 16MB if the machine had enough memory available,
> to free up ZONE_DMA. Or not do that if running on a <= 16MB machine.
>

The only machines on which ZONE_DMA matters (machines with ISA DMA
devices) are also the ones which are likely to be <= 16 MB.

Yes, there are floppies, but I think having over 3 MB available for
floppy DMA is plenty, and floppies are FINALLY going away...

-hpa