linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* Patch to make the head.S-must-be-first-in-vmlinux order explicit
@ 2006-02-23 13:19 Arjan van de Ven
  2006-02-23 13:42 ` Andi Kleen
  2006-02-23 15:09 ` Patch to reorder functions in the vmlinux to a defined order Arjan van de Ven
  0 siblings, 2 replies; 60+ messages in thread
From: Arjan van de Ven @ 2006-02-23 13:19 UTC (permalink / raw)
  To: ak, linux-kernel; +Cc: akpm

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 <arjan@linux.intel.com>
---
 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


^ permalink raw reply	[flat|nested] 60+ messages in thread

* Re: Patch to make the head.S-must-be-first-in-vmlinux order explicit
  2006-02-23 13:19 Patch to make the head.S-must-be-first-in-vmlinux order explicit Arjan van de Ven
@ 2006-02-23 13:42 ` Andi Kleen
  2006-02-23 13:57   ` Arjan van de Ven
  2006-02-23 15:09 ` Patch to reorder functions in the vmlinux to a defined order Arjan van de Ven
  1 sibling, 1 reply; 60+ messages in thread
From: Andi Kleen @ 2006-02-23 13:42 UTC (permalink / raw)
  To: Arjan van de Ven; +Cc: linux-kernel, akpm

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

^ permalink raw reply	[flat|nested] 60+ messages in thread

* Re: Patch to make the head.S-must-be-first-in-vmlinux order explicit
  2006-02-23 13:42 ` Andi Kleen
@ 2006-02-23 13:57   ` Arjan van de Ven
  2006-02-23 14:14     ` Andi Kleen
  0 siblings, 1 reply; 60+ messages in thread
From: Arjan van de Ven @ 2006-02-23 13:57 UTC (permalink / raw)
  To: Andi Kleen; +Cc: linux-kernel, akpm

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 ;( )


^ permalink raw reply	[flat|nested] 60+ messages in thread

* Re: Patch to make the head.S-must-be-first-in-vmlinux order explicit
  2006-02-23 13:57   ` Arjan van de Ven
@ 2006-02-23 14:14     ` Andi Kleen
  2006-02-23 14:40       ` Arjan van de Ven
  2006-02-24 13:49       ` Eric W. Biederman
  0 siblings, 2 replies; 60+ messages in thread
From: Andi Kleen @ 2006-02-23 14:14 UTC (permalink / raw)
  To: Arjan van de Ven; +Cc: linux-kernel, akpm

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

^ permalink raw reply	[flat|nested] 60+ messages in thread

* Re: Patch to make the head.S-must-be-first-in-vmlinux order explicit
  2006-02-23 14:14     ` Andi Kleen
@ 2006-02-23 14:40       ` Arjan van de Ven
  2006-02-24 13:49       ` Eric W. Biederman
  1 sibling, 0 replies; 60+ messages in thread
From: Arjan van de Ven @ 2006-02-23 14:40 UTC (permalink / raw)
  To: Andi Kleen; +Cc: linux-kernel, akpm

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


^ permalink raw reply	[flat|nested] 60+ messages in thread

* Patch to reorder functions in the vmlinux to a defined order
  2006-02-23 13:19 Patch to make the head.S-must-be-first-in-vmlinux order explicit Arjan van de Ven
  2006-02-23 13:42 ` Andi Kleen
@ 2006-02-23 15:09 ` Arjan van de Ven
  2006-02-23 16:00   ` Andi Kleen
                     ` (4 more replies)
  1 sibling, 5 replies; 60+ messages in thread
From: Arjan van de Ven @ 2006-02-23 15:09 UTC (permalink / raw)
  To: linux-kernel, ak; +Cc: torvalds, akpm, mingo

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 <arjan@linux.intel.com>

---
 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";
+  }
+}


^ permalink raw reply	[flat|nested] 60+ messages in thread

* Re: Patch to reorder functions in the vmlinux to a defined order
  2006-02-23 15:09 ` Patch to reorder functions in the vmlinux to a defined order Arjan van de Ven
@ 2006-02-23 16:00   ` Andi Kleen
  2006-02-23 16:02     ` Arjan van de Ven
  2006-02-23 16:43     ` Arjan van de Ven
  2006-02-23 16:48   ` Linus Torvalds
                     ` (3 subsequent siblings)
  4 siblings, 2 replies; 60+ messages in thread
From: Andi Kleen @ 2006-02-23 16:00 UTC (permalink / raw)
  To: Arjan van de Ven; +Cc: linux-kernel, torvalds, akpm, mingo

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

^ permalink raw reply	[flat|nested] 60+ messages in thread

* Re: Patch to reorder functions in the vmlinux to a defined order
  2006-02-23 16:00   ` Andi Kleen
@ 2006-02-23 16:02     ` Arjan van de Ven
  2006-02-23 16:43     ` Arjan van de Ven
  1 sibling, 0 replies; 60+ messages in thread
From: Arjan van de Ven @ 2006-02-23 16:02 UTC (permalink / raw)
  To: Andi Kleen; +Cc: linux-kernel, torvalds, akpm, mingo

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

^ permalink raw reply	[flat|nested] 60+ messages in thread

* Re: Patch to reorder functions in the vmlinux to a defined order
  2006-02-23 16:00   ` Andi Kleen
  2006-02-23 16:02     ` Arjan van de Ven
@ 2006-02-23 16:43     ` Arjan van de Ven
  2006-02-23 16:48       ` Andi Kleen
  2006-02-23 17:08       ` Linus Torvalds
  1 sibling, 2 replies; 60+ messages in thread
From: Arjan van de Ven @ 2006-02-23 16:43 UTC (permalink / raw)
  To: Andi Kleen; +Cc: linux-kernel, torvalds, akpm, mingo

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 <arjan@linux.intel.com>

---
 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


^ permalink raw reply	[flat|nested] 60+ messages in thread

* Re: Patch to reorder functions in the vmlinux to a defined order
  2006-02-23 15:09 ` Patch to reorder functions in the vmlinux to a defined order Arjan van de Ven
  2006-02-23 16:00   ` Andi Kleen
@ 2006-02-23 16:48   ` Linus Torvalds
  2006-02-23 16:54     ` Benjamin LaHaise
  2006-02-23 18:01     ` Arjan van de Ven
  2006-02-23 16:57   ` linux-os (Dick Johnson)
                     ` (2 subsequent siblings)
  4 siblings, 2 replies; 60+ messages in thread
From: Linus Torvalds @ 2006-02-23 16:48 UTC (permalink / raw)
  To: Arjan van de Ven
  Cc: Linux Kernel Mailing List, ak, Andrew Morton, Ingo Molnar



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

^ permalink raw reply	[flat|nested] 60+ messages in thread

* Re: Patch to reorder functions in the vmlinux to a defined order
  2006-02-23 16:43     ` Arjan van de Ven
@ 2006-02-23 16:48       ` Andi Kleen
  2006-02-23 16:49         ` Arjan van de Ven
  2006-02-23 17:08       ` Linus Torvalds
  1 sibling, 1 reply; 60+ messages in thread
From: Andi Kleen @ 2006-02-23 16:48 UTC (permalink / raw)
  To: Arjan van de Ven; +Cc: linux-kernel, torvalds, akpm, mingo

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

^ permalink raw reply	[flat|nested] 60+ messages in thread

* Re: Patch to reorder functions in the vmlinux to a defined order
  2006-02-23 16:48       ` Andi Kleen
@ 2006-02-23 16:49         ` Arjan van de Ven
  0 siblings, 0 replies; 60+ messages in thread
From: Arjan van de Ven @ 2006-02-23 16:49 UTC (permalink / raw)
  To: Andi Kleen; +Cc: linux-kernel, torvalds, akpm, mingo

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

^ permalink raw reply	[flat|nested] 60+ messages in thread

* Re: Patch to reorder functions in the vmlinux to a defined order
  2006-02-23 16:48   ` Linus Torvalds
@ 2006-02-23 16:54     ` Benjamin LaHaise
  2006-02-23 18:01     ` Arjan van de Ven
  1 sibling, 0 replies; 60+ messages in thread
From: Benjamin LaHaise @ 2006-02-23 16:54 UTC (permalink / raw)
  To: Linus Torvalds
  Cc: Arjan van de Ven, Linux Kernel Mailing List, ak, Andrew Morton,
	Ingo Molnar

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: <dont@kvack.org>.

^ permalink raw reply	[flat|nested] 60+ messages in thread

* Re: Patch to reorder functions in the vmlinux to a defined order
  2006-02-23 15:09 ` Patch to reorder functions in the vmlinux to a defined order Arjan van de Ven
  2006-02-23 16:00   ` Andi Kleen
  2006-02-23 16:48   ` Linus Torvalds
@ 2006-02-23 16:57   ` linux-os (Dick Johnson)
  2006-02-23 17:36   ` Zwane Mwaikambo
  2006-02-24 22:19   ` Tony Luck
  4 siblings, 0 replies; 60+ messages in thread
From: linux-os (Dick Johnson) @ 2006-02-23 16:57 UTC (permalink / raw)
  To: Arjan van de Ven; +Cc: linux-kernel, ak, torvalds, akpm, mingo


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 <arjan@linux.intel.com>
>
> ---
> 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.
_
\x1a\x04

****************************************************************
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 DeliveryErrors@analogic.com - and destroy all copies of this information, including any attachments, without reading or disclosing them.

Thank you.

^ permalink raw reply	[flat|nested] 60+ messages in thread

* Re: Patch to reorder functions in the vmlinux to a defined order
  2006-02-23 16:43     ` Arjan van de Ven
  2006-02-23 16:48       ` Andi Kleen
@ 2006-02-23 17:08       ` Linus Torvalds
  2006-02-23 17:20         ` Andi Kleen
                           ` (3 more replies)
  1 sibling, 4 replies; 60+ messages in thread
From: Linus Torvalds @ 2006-02-23 17:08 UTC (permalink / raw)
  To: Arjan van de Ven; +Cc: Andi Kleen, linux-kernel, akpm, mingo



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

^ permalink raw reply related	[flat|nested] 60+ messages in thread

* Re: Patch to reorder functions in the vmlinux to a defined order
  2006-02-23 17:08       ` Linus Torvalds
@ 2006-02-23 17:20         ` Andi Kleen
  2006-02-23 17:34           ` Alan Cox
  2006-02-23 17:44           ` Linus Torvalds
  2006-02-23 19:03         ` linux-os (Dick Johnson)
                           ` (2 subsequent siblings)
  3 siblings, 2 replies; 60+ messages in thread
From: Andi Kleen @ 2006-02-23 17:20 UTC (permalink / raw)
  To: Linus Torvalds; +Cc: Arjan van de Ven, linux-kernel, akpm, mingo

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


^ permalink raw reply	[flat|nested] 60+ messages in thread

* Re: Patch to reorder functions in the vmlinux to a defined order
  2006-02-23 17:20         ` Andi Kleen
@ 2006-02-23 17:34           ` Alan Cox
  2006-02-23 18:13             ` Andi Kleen
  2006-02-23 17:44           ` Linus Torvalds
  1 sibling, 1 reply; 60+ messages in thread
From: Alan Cox @ 2006-02-23 17:34 UTC (permalink / raw)
  To: Andi Kleen; +Cc: Linus Torvalds, Arjan van de Ven, linux-kernel, akpm, mingo

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


^ permalink raw reply	[flat|nested] 60+ messages in thread

* Re: Patch to reorder functions in the vmlinux to a defined order
  2006-02-23 15:09 ` Patch to reorder functions in the vmlinux to a defined order Arjan van de Ven
                     ` (2 preceding siblings ...)
  2006-02-23 16:57   ` linux-os (Dick Johnson)
@ 2006-02-23 17:36   ` Zwane Mwaikambo
  2006-02-23 17:59     ` Arjan van de Ven
  2006-02-24 22:19   ` Tony Luck
  4 siblings, 1 reply; 60+ messages in thread
From: Zwane Mwaikambo @ 2006-02-23 17:36 UTC (permalink / raw)
  To: Arjan van de Ven; +Cc: linux-kernel, ak, torvalds, akpm, mingo

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.

^ permalink raw reply	[flat|nested] 60+ messages in thread

* Re: Patch to reorder functions in the vmlinux to a defined order
  2006-02-23 17:20         ` Andi Kleen
  2006-02-23 17:34           ` Alan Cox
@ 2006-02-23 17:44           ` Linus Torvalds
  2006-02-23 18:14             ` Andi Kleen
  1 sibling, 1 reply; 60+ messages in thread
From: Linus Torvalds @ 2006-02-23 17:44 UTC (permalink / raw)
  To: Andi Kleen; +Cc: Arjan van de Ven, linux-kernel, akpm, mingo



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

^ permalink raw reply	[flat|nested] 60+ messages in thread

* Re: Patch to reorder functions in the vmlinux to a defined order
  2006-02-23 17:36   ` Zwane Mwaikambo
@ 2006-02-23 17:59     ` Arjan van de Ven
  0 siblings, 0 replies; 60+ messages in thread
From: Arjan van de Ven @ 2006-02-23 17:59 UTC (permalink / raw)
  To: Zwane Mwaikambo; +Cc: linux-kernel, ak, torvalds, akpm, mingo

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.


^ permalink raw reply	[flat|nested] 60+ messages in thread

* Re: Patch to reorder functions in the vmlinux to a defined order
  2006-02-23 16:48   ` Linus Torvalds
  2006-02-23 16:54     ` Benjamin LaHaise
@ 2006-02-23 18:01     ` Arjan van de Ven
  1 sibling, 0 replies; 60+ messages in thread
From: Arjan van de Ven @ 2006-02-23 18:01 UTC (permalink / raw)
  To: Linus Torvalds; +Cc: Linux Kernel Mailing List, ak, Andrew Morton, Ingo Molnar

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

^ permalink raw reply	[flat|nested] 60+ messages in thread

* Re: Patch to reorder functions in the vmlinux to a defined order
  2006-02-23 17:34           ` Alan Cox
@ 2006-02-23 18:13             ` Andi Kleen
  0 siblings, 0 replies; 60+ messages in thread
From: Andi Kleen @ 2006-02-23 18:13 UTC (permalink / raw)
  To: Alan Cox; +Cc: Linus Torvalds, Arjan van de Ven, linux-kernel, akpm, mingo

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

^ permalink raw reply	[flat|nested] 60+ messages in thread

* Re: Patch to reorder functions in the vmlinux to a defined order
  2006-02-23 17:44           ` Linus Torvalds
@ 2006-02-23 18:14             ` Andi Kleen
  0 siblings, 0 replies; 60+ messages in thread
From: Andi Kleen @ 2006-02-23 18:14 UTC (permalink / raw)
  To: Linus Torvalds; +Cc: Arjan van de Ven, linux-kernel, akpm, mingo

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

^ permalink raw reply	[flat|nested] 60+ messages in thread

* Re: Patch to reorder functions in the vmlinux to a defined order
  2006-02-23 17:08       ` Linus Torvalds
  2006-02-23 17:20         ` Andi Kleen
@ 2006-02-23 19:03         ` linux-os (Dick Johnson)
  2006-02-23 19:32           ` Linus Torvalds
  2006-02-23 19:23         ` Rene Herman
  2006-02-23 20:07         ` Andy Whitcroft
  3 siblings, 1 reply; 60+ messages in thread
From: linux-os (Dick Johnson) @ 2006-02-23 19:03 UTC (permalink / raw)
  To: Linus Torvalds; +Cc: Arjan van de Ven, Andi Kleen, linux-kernel, akpm, mingo


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.
_
\x1a\x04

****************************************************************
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 DeliveryErrors@analogic.com - and destroy all copies of this information, including any attachments, without reading or disclosing them.

Thank you.

^ permalink raw reply	[flat|nested] 60+ messages in thread

* Re: Patch to reorder functions in the vmlinux to a defined order
  2006-02-23 17:08       ` Linus Torvalds
  2006-02-23 17:20         ` Andi Kleen
  2006-02-23 19:03         ` linux-os (Dick Johnson)
@ 2006-02-23 19:23         ` Rene Herman
  2006-02-23 19:31           ` Andi Kleen
                             ` (2 more replies)
  2006-02-23 20:07         ` Andy Whitcroft
  3 siblings, 3 replies; 60+ messages in thread
From: Rene Herman @ 2006-02-23 19:23 UTC (permalink / raw)
  To: Linus Torvalds; +Cc: Arjan van de Ven, Andi Kleen, linux-kernel, akpm, mingo

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.

^ permalink raw reply	[flat|nested] 60+ messages in thread

* Re: Patch to reorder functions in the vmlinux to a defined order
  2006-02-23 19:23         ` Rene Herman
@ 2006-02-23 19:31           ` Andi Kleen
  2006-02-23 19:34           ` Alan Cox
  2006-02-23 19:35           ` Linus Torvalds
  2 siblings, 0 replies; 60+ messages in thread
From: Andi Kleen @ 2006-02-23 19:31 UTC (permalink / raw)
  To: Rene Herman; +Cc: Linus Torvalds, Arjan van de Ven, linux-kernel, akpm, mingo

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


^ permalink raw reply	[flat|nested] 60+ messages in thread

* Re: Patch to reorder functions in the vmlinux to a defined order
  2006-02-23 19:03         ` linux-os (Dick Johnson)
@ 2006-02-23 19:32           ` Linus Torvalds
  2006-02-24 12:43             ` linux-os (Dick Johnson)
  0 siblings, 1 reply; 60+ messages in thread
From: Linus Torvalds @ 2006-02-23 19:32 UTC (permalink / raw)
  To: linux-os (Dick Johnson)
  Cc: Arjan van de Ven, Andi Kleen, linux-kernel, akpm, mingo



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

^ permalink raw reply	[flat|nested] 60+ messages in thread

* Re: Patch to reorder functions in the vmlinux to a defined order
  2006-02-23 19:23         ` Rene Herman
  2006-02-23 19:31           ` Andi Kleen
@ 2006-02-23 19:34           ` Alan Cox
  2006-02-23 19:48             ` Rene Herman
  2006-02-23 19:35           ` Linus Torvalds
  2 siblings, 1 reply; 60+ messages in thread
From: Alan Cox @ 2006-02-23 19:34 UTC (permalink / raw)
  To: Rene Herman
  Cc: Linus Torvalds, Arjan van de Ven, Andi Kleen, linux-kernel, akpm, mingo

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.



^ permalink raw reply	[flat|nested] 60+ messages in thread

* Re: Patch to reorder functions in the vmlinux to a defined order
  2006-02-23 19:23         ` Rene Herman
  2006-02-23 19:31           ` Andi Kleen
  2006-02-23 19:34           ` Alan Cox
@ 2006-02-23 19:35           ` Linus Torvalds
  2006-02-23 19:44             ` Arjan van de Ven
                               ` (2 more replies)
  2 siblings, 3 replies; 60+ messages in thread
From: Linus Torvalds @ 2006-02-23 19:35 UTC (permalink / raw)
  To: Rene Herman; +Cc: Arjan van de Ven, Andi Kleen, linux-kernel, akpm, mingo



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

^ permalink raw reply	[flat|nested] 60+ messages in thread

* Re: Patch to reorder functions in the vmlinux to a defined order
  2006-02-23 19:35           ` Linus Torvalds
@ 2006-02-23 19:44             ` Arjan van de Ven
  2006-02-23 20:13             ` Rene Herman
  2006-02-24  1:38             ` Martin Bligh
  2 siblings, 0 replies; 60+ messages in thread
From: Arjan van de Ven @ 2006-02-23 19:44 UTC (permalink / raw)
  To: Linus Torvalds; +Cc: Rene Herman, Andi Kleen, linux-kernel, akpm, mingo

\
> 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


^ permalink raw reply	[flat|nested] 60+ messages in thread

* Re: Patch to reorder functions in the vmlinux to a defined order
  2006-02-23 19:34           ` Alan Cox
@ 2006-02-23 19:48             ` Rene Herman
  0 siblings, 0 replies; 60+ messages in thread
From: Rene Herman @ 2006-02-23 19:48 UTC (permalink / raw)
  To: Alan Cox
  Cc: Linus Torvalds, Arjan van de Ven, Andi Kleen, linux-kernel, akpm, mingo

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.


^ permalink raw reply	[flat|nested] 60+ messages in thread

* Re: Patch to reorder functions in the vmlinux to a defined order
  2006-02-23 17:08       ` Linus Torvalds
                           ` (2 preceding siblings ...)
  2006-02-23 19:23         ` Rene Herman
@ 2006-02-23 20:07         ` Andy Whitcroft
  3 siblings, 0 replies; 60+ messages in thread
From: Andy Whitcroft @ 2006-02-23 20:07 UTC (permalink / raw)
  To: Linus Torvalds; +Cc: Arjan van de Ven, Andi Kleen, linux-kernel, akpm, mingo

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

^ permalink raw reply	[flat|nested] 60+ messages in thread

* Re: Patch to reorder functions in the vmlinux to a defined order
  2006-02-23 19:35           ` Linus Torvalds
  2006-02-23 19:44             ` Arjan van de Ven
@ 2006-02-23 20:13             ` Rene Herman
  2006-02-23 20:26               ` Dave Jones
  2006-02-23 23:19               ` Linus Torvalds
  2006-02-24  1:38             ` Martin Bligh
  2 siblings, 2 replies; 60+ messages in thread
From: Rene Herman @ 2006-02-23 20:13 UTC (permalink / raw)
  To: Linus Torvalds; +Cc: Arjan van de Ven, Andi Kleen, linux-kernel, akpm, mingo

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.

^ permalink raw reply	[flat|nested] 60+ messages in thread

* Re: Patch to reorder functions in the vmlinux to a defined order
  2006-02-23 20:13             ` Rene Herman
@ 2006-02-23 20:26               ` Dave Jones
  2006-02-24  2:44                 ` Fernando Luis Vazquez Cao
  2006-02-23 23:19               ` Linus Torvalds
  1 sibling, 1 reply; 60+ messages in thread
From: Dave Jones @ 2006-02-23 20:26 UTC (permalink / raw)
  To: Rene Herman
  Cc: Linus Torvalds, Arjan van de Ven, Andi Kleen, linux-kernel, akpm, mingo

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


^ permalink raw reply	[flat|nested] 60+ messages in thread

* Re: Patch to reorder functions in the vmlinux to a defined order
  2006-02-23 20:13             ` Rene Herman
  2006-02-23 20:26               ` Dave Jones
@ 2006-02-23 23:19               ` Linus Torvalds
  2006-02-23 23:53                 ` Rene Herman
  2006-02-24 14:11                 ` Eric W. Biederman
  1 sibling, 2 replies; 60+ messages in thread
From: Linus Torvalds @ 2006-02-23 23:19 UTC (permalink / raw)
  To: Rene Herman; +Cc: Arjan van de Ven, Andi Kleen, linux-kernel, akpm, mingo



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

^ permalink raw reply	[flat|nested] 60+ messages in thread

* Re: Patch to reorder functions in the vmlinux to a defined order
  2006-02-23 23:19               ` Linus Torvalds
@ 2006-02-23 23:53                 ` Rene Herman
  2006-02-24 14:23                   ` Eric W. Biederman
  2006-02-24 14:23                   ` Eric W. Biederman
  2006-02-24 14:11                 ` Eric W. Biederman
  1 sibling, 2 replies; 60+ messages in thread
From: Rene Herman @ 2006-02-23 23:53 UTC (permalink / raw)
  To: Linus Torvalds; +Cc: Arjan van de Ven, Andi Kleen, linux-kernel, akpm, mingo

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.

^ permalink raw reply	[flat|nested] 60+ messages in thread

* Re: Patch to reorder functions in the vmlinux to a defined order
  2006-02-23 19:35           ` Linus Torvalds
  2006-02-23 19:44             ` Arjan van de Ven
  2006-02-23 20:13             ` Rene Herman
@ 2006-02-24  1:38             ` Martin Bligh
  2 siblings, 0 replies; 60+ messages in thread
From: Martin Bligh @ 2006-02-24  1:38 UTC (permalink / raw)
  To: Linus Torvalds
  Cc: Rene Herman, Arjan van de Ven, Andi Kleen, linux-kernel, akpm, mingo

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.

^ permalink raw reply	[flat|nested] 60+ messages in thread

* Re: Patch to reorder functions in the vmlinux to a defined order
  2006-02-23 20:26               ` Dave Jones
@ 2006-02-24  2:44                 ` Fernando Luis Vazquez Cao
  2006-02-24  2:47                   ` Andi Kleen
  2006-02-24 14:44                   ` Theodore Ts'o
  0 siblings, 2 replies; 60+ messages in thread
From: Fernando Luis Vazquez Cao @ 2006-02-24  2:44 UTC (permalink / raw)
  To: Dave Jones
  Cc: Rene Herman, Linus Torvalds, Arjan van de Ven, Andi Kleen,
	linux-kernel, akpm, mingo

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


^ permalink raw reply	[flat|nested] 60+ messages in thread

* Re: Patch to reorder functions in the vmlinux to a defined order
  2006-02-24  2:44                 ` Fernando Luis Vazquez Cao
@ 2006-02-24  2:47                   ` Andi Kleen
  2006-02-24 14:44                   ` Theodore Ts'o
  1 sibling, 0 replies; 60+ messages in thread
From: Andi Kleen @ 2006-02-24  2:47 UTC (permalink / raw)
  To: Fernando Luis Vazquez Cao
  Cc: Dave Jones, Rene Herman, Linus Torvalds, Arjan van de Ven,
	linux-kernel, akpm, mingo

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

^ permalink raw reply	[flat|nested] 60+ messages in thread

* Re: Patch to reorder functions in the vmlinux to a defined order
  2006-02-23 19:32           ` Linus Torvalds
@ 2006-02-24 12:43             ` linux-os (Dick Johnson)
  0 siblings, 0 replies; 60+ messages in thread
From: linux-os (Dick Johnson) @ 2006-02-24 12:43 UTC (permalink / raw)
  To: Linus Torvalds; +Cc: Arjan van de Ven, Andi Kleen, linux-kernel, akpm, mingo


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.
_
\x1a\x04

****************************************************************
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 DeliveryErrors@analogic.com - and destroy all copies of this information, including any attachments, without reading or disclosing them.

Thank you.

^ permalink raw reply	[flat|nested] 60+ messages in thread

* Re: Patch to make the head.S-must-be-first-in-vmlinux order explicit
  2006-02-23 14:14     ` Andi Kleen
  2006-02-23 14:40       ` Arjan van de Ven
@ 2006-02-24 13:49       ` Eric W. Biederman
  2006-02-24 13:53         ` Arjan van de Ven
  1 sibling, 1 reply; 60+ messages in thread
From: Eric W. Biederman @ 2006-02-24 13:49 UTC (permalink / raw)
  To: Andi Kleen; +Cc: Arjan van de Ven, linux-kernel, akpm

Andi Kleen <ak@suse.de> 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

^ permalink raw reply	[flat|nested] 60+ messages in thread

* Re: Patch to make the head.S-must-be-first-in-vmlinux order explicit
  2006-02-24 13:49       ` Eric W. Biederman
@ 2006-02-24 13:53         ` Arjan van de Ven
  2006-02-24 14:17           ` Eric W. Biederman
  2006-02-24 14:32           ` Andi Kleen
  0 siblings, 2 replies; 60+ messages in thread
From: Arjan van de Ven @ 2006-02-24 13:53 UTC (permalink / raw)
  To: Eric W. Biederman; +Cc: Andi Kleen, linux-kernel, akpm

Eric W. Biederman wrote:
> Andi Kleen <ak@suse.de> 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....

^ permalink raw reply	[flat|nested] 60+ messages in thread

* Re: Patch to reorder functions in the vmlinux to a defined order
  2006-02-23 23:19               ` Linus Torvalds
  2006-02-23 23:53                 ` Rene Herman
@ 2006-02-24 14:11                 ` Eric W. Biederman
  1 sibling, 0 replies; 60+ messages in thread
From: Eric W. Biederman @ 2006-02-24 14:11 UTC (permalink / raw)
  To: Linus Torvalds
  Cc: Rene Herman, Arjan van de Ven, Andi Kleen, linux-kernel, akpm, mingo

Linus Torvalds <torvalds@osdl.org> 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

^ permalink raw reply	[flat|nested] 60+ messages in thread

* Re: Patch to make the head.S-must-be-first-in-vmlinux order explicit
  2006-02-24 13:53         ` Arjan van de Ven
@ 2006-02-24 14:17           ` Eric W. Biederman
  2006-02-24 14:32           ` Andi Kleen
  1 sibling, 0 replies; 60+ messages in thread
From: Eric W. Biederman @ 2006-02-24 14:17 UTC (permalink / raw)
  To: Arjan van de Ven; +Cc: Andi Kleen, linux-kernel, akpm

Arjan van de Ven <arjan@linux.intel.com> writes:

> Eric W. Biederman wrote:
>> Andi Kleen <ak@suse.de> 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

^ permalink raw reply	[flat|nested] 60+ messages in thread

* Re: Patch to reorder functions in the vmlinux to a defined order
  2006-02-23 23:53                 ` Rene Herman
@ 2006-02-24 14:23                   ` Eric W. Biederman
  2006-02-24 14:23                   ` Eric W. Biederman
  1 sibling, 0 replies; 60+ messages in thread
From: Eric W. Biederman @ 2006-02-24 14:23 UTC (permalink / raw)
  To: Rene Herman
  Cc: Linus Torvalds, Arjan van de Ven, Andi Kleen, linux-kernel, akpm, mingo

Rene Herman <rene.herman@keyaccess.nl> 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

^ permalink raw reply	[flat|nested] 60+ messages in thread

* Re: Patch to reorder functions in the vmlinux to a defined order
  2006-02-23 23:53                 ` Rene Herman
  2006-02-24 14:23                   ` Eric W. Biederman
@ 2006-02-24 14:23                   ` Eric W. Biederman
  2006-02-24 15:30                     ` Rene Herman
  1 sibling, 1 reply; 60+ messages in thread
From: Eric W. Biederman @ 2006-02-24 14:23 UTC (permalink / raw)
  To: Rene Herman
  Cc: Linus Torvalds, Arjan van de Ven, Andi Kleen, linux-kernel, akpm, mingo

Rene Herman <rene.herman@keyaccess.nl> 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

^ permalink raw reply	[flat|nested] 60+ messages in thread

* Re: Patch to make the head.S-must-be-first-in-vmlinux order explicit
  2006-02-24 13:53         ` Arjan van de Ven
  2006-02-24 14:17           ` Eric W. Biederman
@ 2006-02-24 14:32           ` Andi Kleen
  1 sibling, 0 replies; 60+ messages in thread
From: Andi Kleen @ 2006-02-24 14:32 UTC (permalink / raw)
  To: Arjan van de Ven; +Cc: Eric W. Biederman, linux-kernel, akpm

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

^ permalink raw reply	[flat|nested] 60+ messages in thread

* Re: Patch to reorder functions in the vmlinux to a defined order
  2006-02-24  2:44                 ` Fernando Luis Vazquez Cao
  2006-02-24  2:47                   ` Andi Kleen
@ 2006-02-24 14:44                   ` Theodore Ts'o
  1 sibling, 0 replies; 60+ messages in thread
From: Theodore Ts'o @ 2006-02-24 14:44 UTC (permalink / raw)
  To: Fernando Luis Vazquez Cao
  Cc: Dave Jones, Rene Herman, Linus Torvalds, Arjan van de Ven,
	Andi Kleen, linux-kernel, akpm, mingo

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

^ permalink raw reply	[flat|nested] 60+ messages in thread

* Re: Patch to reorder functions in the vmlinux to a defined order
  2006-02-24 14:23                   ` Eric W. Biederman
@ 2006-02-24 15:30                     ` Rene Herman
  2006-02-24 15:55                       ` Eric W. Biederman
  0 siblings, 1 reply; 60+ messages in thread
From: Rene Herman @ 2006-02-24 15:30 UTC (permalink / raw)
  To: Eric W. Biederman
  Cc: Linus Torvalds, Arjan van de Ven, Andi Kleen, linux-kernel, akpm, mingo

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.

^ permalink raw reply	[flat|nested] 60+ messages in thread

* Re: Patch to reorder functions in the vmlinux to a defined order
  2006-02-24 15:30                     ` Rene Herman
@ 2006-02-24 15:55                       ` Eric W. Biederman
  2006-02-24 16:48                         ` Andi Kleen
  2006-02-24 17:26                         ` Linus Torvalds
  0 siblings, 2 replies; 60+ messages in thread
From: Eric W. Biederman @ 2006-02-24 15:55 UTC (permalink / raw)
  To: Rene Herman
  Cc: Linus Torvalds, Arjan van de Ven, Andi Kleen, linux-kernel, akpm, mingo

Rene Herman <rene.herman@keyaccess.nl> 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

^ permalink raw reply	[flat|nested] 60+ messages in thread

* Re: Patch to reorder functions in the vmlinux to a defined order
  2006-02-24 15:55                       ` Eric W. Biederman
@ 2006-02-24 16:48                         ` Andi Kleen
  2006-02-24 20:38                           ` Eric W. Biederman
  2006-02-24 17:26                         ` Linus Torvalds
  1 sibling, 1 reply; 60+ messages in thread
From: Andi Kleen @ 2006-02-24 16:48 UTC (permalink / raw)
  To: Eric W. Biederman
  Cc: Rene Herman, Linus Torvalds, Arjan van de Ven, linux-kernel, akpm, mingo

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

^ permalink raw reply	[flat|nested] 60+ messages in thread

* Re: Patch to reorder functions in the vmlinux to a defined order
  2006-02-24 15:55                       ` Eric W. Biederman
  2006-02-24 16:48                         ` Andi Kleen
@ 2006-02-24 17:26                         ` Linus Torvalds
  2006-02-24 17:57                           ` Rene Herman
  1 sibling, 1 reply; 60+ messages in thread
From: Linus Torvalds @ 2006-02-24 17:26 UTC (permalink / raw)
  To: Eric W. Biederman
  Cc: Rene Herman, Arjan van de Ven, Andi Kleen, linux-kernel, akpm, mingo



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

^ permalink raw reply	[flat|nested] 60+ messages in thread

* Re: Patch to reorder functions in the vmlinux to a defined order
  2006-02-24 17:26                         ` Linus Torvalds
@ 2006-02-24 17:57                           ` Rene Herman
  2006-02-24 18:11                             ` Linus Torvalds
  2006-03-07 23:36                             ` H. Peter Anvin
  0 siblings, 2 replies; 60+ messages in thread
From: Rene Herman @ 2006-02-24 17:57 UTC (permalink / raw)
  To: Linus Torvalds
  Cc: Eric W. Biederman, Arjan van de Ven, Andi Kleen, linux-kernel,
	akpm, mingo

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.


^ permalink raw reply	[flat|nested] 60+ messages in thread

* Re: Patch to reorder functions in the vmlinux to a defined order
  2006-02-24 17:57                           ` Rene Herman
@ 2006-02-24 18:11                             ` Linus Torvalds
  2006-03-07 23:36                             ` H. Peter Anvin
  1 sibling, 0 replies; 60+ messages in thread
From: Linus Torvalds @ 2006-02-24 18:11 UTC (permalink / raw)
  To: Rene Herman
  Cc: Eric W. Biederman, Arjan van de Ven, Andi Kleen, linux-kernel,
	akpm, mingo



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

^ permalink raw reply	[flat|nested] 60+ messages in thread

* Re: Patch to reorder functions in the vmlinux to a defined order
  2006-02-24 16:48                         ` Andi Kleen
@ 2006-02-24 20:38                           ` Eric W. Biederman
  2006-02-25  2:11                             ` Folkert van Heusden
  0 siblings, 1 reply; 60+ messages in thread
From: Eric W. Biederman @ 2006-02-24 20:38 UTC (permalink / raw)
  To: Andi Kleen
  Cc: Rene Herman, Linus Torvalds, Arjan van de Ven, linux-kernel, akpm, mingo

Andi Kleen <ak@suse.de> 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

^ permalink raw reply	[flat|nested] 60+ messages in thread

* Re: Patch to reorder functions in the vmlinux to a defined order
  2006-02-23 15:09 ` Patch to reorder functions in the vmlinux to a defined order Arjan van de Ven
                     ` (3 preceding siblings ...)
  2006-02-23 17:36   ` Zwane Mwaikambo
@ 2006-02-24 22:19   ` Tony Luck
  2006-02-24 22:21     ` Arjan van de Ven
  4 siblings, 1 reply; 60+ messages in thread
From: Tony Luck @ 2006-02-24 22:19 UTC (permalink / raw)
  To: Arjan van de Ven; +Cc: linux-kernel, ak, torvalds, akpm, mingo

On 2/23/06, Arjan van de Ven <arjan@linux.intel.com> 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 :)

^ permalink raw reply	[flat|nested] 60+ messages in thread

* Re: Patch to reorder functions in the vmlinux to a defined order
  2006-02-24 22:19   ` Tony Luck
@ 2006-02-24 22:21     ` Arjan van de Ven
  0 siblings, 0 replies; 60+ messages in thread
From: Arjan van de Ven @ 2006-02-24 22:21 UTC (permalink / raw)
  To: Tony Luck; +Cc: linux-kernel, ak, torvalds, akpm, mingo

Tony Luck wrote:
> On 2/23/06, Arjan van de Ven <arjan@linux.intel.com> 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.


^ permalink raw reply	[flat|nested] 60+ messages in thread

* Re: Patch to reorder functions in the vmlinux to a defined order
  2006-02-24 20:38                           ` Eric W. Biederman
@ 2006-02-25  2:11                             ` Folkert van Heusden
  2006-02-25  8:32                               ` Arjan van de Ven
  0 siblings, 1 reply; 60+ messages in thread
From: Folkert van Heusden @ 2006-02-25  2:11 UTC (permalink / raw)
  To: Eric W. Biederman; +Cc: linux-kernel

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, www.vanheusden.com

^ permalink raw reply	[flat|nested] 60+ messages in thread

* Re: Patch to reorder functions in the vmlinux to a defined order
  2006-02-25  2:11                             ` Folkert van Heusden
@ 2006-02-25  8:32                               ` Arjan van de Ven
  0 siblings, 0 replies; 60+ messages in thread
From: Arjan van de Ven @ 2006-02-25  8:32 UTC (permalink / raw)
  To: Folkert van Heusden; +Cc: linux-kernel, Eric W. Biederman

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)

^ permalink raw reply	[flat|nested] 60+ messages in thread

* Re: Patch to reorder functions in the vmlinux to a defined order
  2006-02-24 17:57                           ` Rene Herman
  2006-02-24 18:11                             ` Linus Torvalds
@ 2006-03-07 23:36                             ` H. Peter Anvin
  1 sibling, 0 replies; 60+ messages in thread
From: H. Peter Anvin @ 2006-03-07 23:36 UTC (permalink / raw)
  To: linux-kernel

Followup to:  <43FF48F2.70508@keyaccess.nl>
By author:    Rene Herman <rene.herman@keyaccess.nl>
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

^ permalink raw reply	[flat|nested] 60+ messages in thread

end of thread, other threads:[~2006-03-07 23:36 UTC | newest]

Thread overview: 60+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2006-02-23 13:19 Patch to make the head.S-must-be-first-in-vmlinux order explicit Arjan van de Ven
2006-02-23 13:42 ` Andi Kleen
2006-02-23 13:57   ` Arjan van de Ven
2006-02-23 14:14     ` Andi Kleen
2006-02-23 14:40       ` Arjan van de Ven
2006-02-24 13:49       ` Eric W. Biederman
2006-02-24 13:53         ` Arjan van de Ven
2006-02-24 14:17           ` Eric W. Biederman
2006-02-24 14:32           ` Andi Kleen
2006-02-23 15:09 ` Patch to reorder functions in the vmlinux to a defined order Arjan van de Ven
2006-02-23 16:00   ` Andi Kleen
2006-02-23 16:02     ` Arjan van de Ven
2006-02-23 16:43     ` Arjan van de Ven
2006-02-23 16:48       ` Andi Kleen
2006-02-23 16:49         ` Arjan van de Ven
2006-02-23 17:08       ` Linus Torvalds
2006-02-23 17:20         ` Andi Kleen
2006-02-23 17:34           ` Alan Cox
2006-02-23 18:13             ` Andi Kleen
2006-02-23 17:44           ` Linus Torvalds
2006-02-23 18:14             ` Andi Kleen
2006-02-23 19:03         ` linux-os (Dick Johnson)
2006-02-23 19:32           ` Linus Torvalds
2006-02-24 12:43             ` linux-os (Dick Johnson)
2006-02-23 19:23         ` Rene Herman
2006-02-23 19:31           ` Andi Kleen
2006-02-23 19:34           ` Alan Cox
2006-02-23 19:48             ` Rene Herman
2006-02-23 19:35           ` Linus Torvalds
2006-02-23 19:44             ` Arjan van de Ven
2006-02-23 20:13             ` Rene Herman
2006-02-23 20:26               ` Dave Jones
2006-02-24  2:44                 ` Fernando Luis Vazquez Cao
2006-02-24  2:47                   ` Andi Kleen
2006-02-24 14:44                   ` Theodore Ts'o
2006-02-23 23:19               ` Linus Torvalds
2006-02-23 23:53                 ` Rene Herman
2006-02-24 14:23                   ` Eric W. Biederman
2006-02-24 14:23                   ` Eric W. Biederman
2006-02-24 15:30                     ` Rene Herman
2006-02-24 15:55                       ` Eric W. Biederman
2006-02-24 16:48                         ` Andi Kleen
2006-02-24 20:38                           ` Eric W. Biederman
2006-02-25  2:11                             ` Folkert van Heusden
2006-02-25  8:32                               ` Arjan van de Ven
2006-02-24 17:26                         ` Linus Torvalds
2006-02-24 17:57                           ` Rene Herman
2006-02-24 18:11                             ` Linus Torvalds
2006-03-07 23:36                             ` H. Peter Anvin
2006-02-24 14:11                 ` Eric W. Biederman
2006-02-24  1:38             ` Martin Bligh
2006-02-23 20:07         ` Andy Whitcroft
2006-02-23 16:48   ` Linus Torvalds
2006-02-23 16:54     ` Benjamin LaHaise
2006-02-23 18:01     ` Arjan van de Ven
2006-02-23 16:57   ` linux-os (Dick Johnson)
2006-02-23 17:36   ` Zwane Mwaikambo
2006-02-23 17:59     ` Arjan van de Ven
2006-02-24 22:19   ` Tony Luck
2006-02-24 22:21     ` Arjan van de Ven

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).