From: Anton Blanchard <anton@samba.org>
To: linux-kernel@vger.kernel.org
Subject: 2.5.50-BK + 24 CPUs
Date: Mon, 9 Dec 2002 00:09:08 +1100 [thread overview]
Message-ID: <20021208130908.GE19698@krispykreme> (raw)
Hi,
I found time to run a few benchmarks over a largish machine (24 way
ppc64) running 2.5.50-BK from a few days ago.
1. kernel compile benchmark (ie build an x86 2.4.18 kernel)
I hijacked /proc/profile to log functions where we call schedule from.
It shows:
schedules:
56283 total
41984 pipe_wait
9746 do_work
1949 do_exit
1834 sys_wait4
ie during the compile we scheduled 56283 times, and 41984 of them were
caused by pipes. Simple fix, remove -pipe from the Makefile of the
kernel I was building:
schedules:
8497 total
3665 do_work
1878 do_exit
1824 sys_wait4
306 cpu_idle
260 open_namei
256 pipe_wait
Much nicer. Does it make sense to use -pipe in our kernel Makefile these
days? Note "do_work" is a ppc64 assembly function which checks
need_resched and calls schedule if the timeslice has been exceeded. So
its nice to see almost all of the schedules are due to timeslice
expiration, processes exiting or processes doing a wait().
Now we can look at the profile:
profile:
66260 total
54227 cpu_idle
1000 page_remove_rmap
909 __get_page_state
830 page_add_rmap
753 save_remaining_regs
646 do_anonymous_page
529 do_page_fault
475 release_pages
468 pSeries_flush_hash_range
462 pSeries_hpte_insert
266 __copy_tofrom_user
215 zap_pte_range
214 sys_brk
210 __pagevec_lru_add_active
209 buffered_rmqueue
201 find_get_page
185 vm_enough_memory
183 nr_free_pages
Mostly idle time, theres a limit to how much we can parallelize here.
Note: save_remaining_regs is the syscall/interrupt entry path for ppc64.
2. dbench 24
Lets not pay too much attention here but there are a few things to keep
in mind:
schedules:
1635314 total
753694 cpu_idle
357910 ext2_new_block
289189 ext2_free_blocks
123788 ext2_new_inode
95025 ext2_free_inode
Whee, look at all the schedules we took inside the ext2 code. Of course
its due to the superblock lock semaphore.
profile:
370142 total
302615 cpu_idle
8600 __copy_tofrom_user
3119 schedule
2760 current_kernel_time
Lots of idle time in part due to the superblock lock (oh yeah and my
slow to react finger stopping profiling after the benchmark finished).
current_kernel_time makes a recent appearance in the profile, we are
working on a number of things to address this.
3. "University workload"
A benchmark that does lots of shell scripts, cc, troff, etc.
schedules:
470212 total
126262 do_work
86986 ext2_free_blocks
58039 ext2_new_block
53627 cpu_idle
43140 ext2_new_inode
30934 ext2_free_inode
19849 do_exit
18526 sys_wait4
The superblock lock semaphore makes an appearance in the schedule
summary again (ext2_*). Now for the profile:
profile:
136296 total
41592 cpu_idle
16319 page_remove_rmap
7338 page_add_rmap
3583 save_remaining_regs
3072 pSeries_flush_hash_range
2832 release_pages
2584 do_page_fault
2281 find_get_page
2238 pSeries_hpte_insert
2117 copy_page_range
2085 current_kernel_time
2028 zap_pte_range
1886 __get_page_state
1689 atomic_dec_and_lock
No big suprises in the profile. This benchmark tends to be a worst case
scenario for rmap, think of 100s of shells all mapping the same text
pages.
Anton
next reply other threads:[~2002-12-08 13:02 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-12-08 13:09 Anton Blanchard [this message]
2002-12-08 14:49 ` 2.5.50-BK + 24 CPUs Rik van Riel
2002-12-08 16:45 ` Rik van Riel
2002-12-09 14:08 ` Anton Blanchard
2002-12-09 19:29 ` page_remove_rmap Daniel Drown
-- strict thread matches above, loose matches on Subject: below --
2002-12-08 21:22 2.5.50-BK + 24 CPUs Manfred Spraul
2002-12-08 21:28 ` William Lee Irwin III
2002-12-08 23:22 ` David S. Miller
2002-12-08 23:01 ` William Lee Irwin III
2002-12-09 17:03 ` Manfred Spraul
2002-12-09 20:15 ` David S. Miller
2002-12-09 21:12 ` Manfred Spraul
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20021208130908.GE19698@krispykreme \
--to=anton@samba.org \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.