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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox