mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
* smp overhead, and rwlocks considered harmful
@ 2003-03-23  1:58 Andrew Morton
  2003-03-23  3:39 ` David S. Miller
                   ` (3 more replies)
  0 siblings, 4 replies; 10+ messages in thread
From: Andrew Morton @ 2003-03-23  1:58 UTC (permalink / raw)
  To: linux-kernel


I've been looking at the CPU cost of the write() system call.  Time how long
it takes to write a million bytes to an ext2 file, via a million
one-byte-writes:

	time dd if=/dev/zero of=foo bs=1 count=1M

This only uses one CPU.  It takes twice as long on SMP.

On a 2.7GHz P4-HT:

	2.5.65-mm4, UP:
		0.34s user 1.00s system 99% cpu 1.348 total
	2.5.65-mm4, SMP:
		0.41s user 2.04s system 100% cpu 2.445 total

	2.4.21-pre5, UP:
		0.34s user 0.96s system 106% cpu 1.224 total
	2.4.21-pre5, SMP:
		0.42s user 1.95s system 99% cpu 2.372 total

(The small additional overhead in 2.5 is expected - there are more function
calls due to the addition of AIO and there is more setup due to the (large)
writev speedups).


On a 500MHz PIII Xeon:

	500MHz PIII, UP:
		1.08s user 2.90s system 100% cpu 3.971 total
	500MHz PIII, SMP:
		1.13s user 4.86s system 99% cpu 5.999 total


This pretty gross.  About six months back I worked out that across the
lifecycle of a pagecache page (creation via write() through to reclaim via
the page LRU) we take 27 spinlocks and rwlocks.  And this does not even
include semaphores and atomic bitops (I used lockmeter).  I'm not sure it is
this high any more - quite a few things were fixed up, but it is still high.


Profiles for 2.5 on the P4 show that it's all in fget(), fput() and
find_get_page().  Those locked operations are really hurting.

One thing is noteworthy: ia32's read_unlock() is buslocked, whereas
spin_unlock() is not.  So let's see what happens if we convert file_lock
from an rwlock to a spinlock:


2.5.65-mm4, SMP:
	0.34s user 2.00s system 100% cpu 2.329 total

That's a 5% speedup.


And if we were to convert file->f_count to be a nonatomic "int", protected by
files_lock it would probably speed things up further.

I've always been a bit skeptical about rwlocks - if you're holding the lock
for long enough for a significant amount of reader concurrency, you're
holding it for too long.  eg:  tasklist_lock.



SMP:

c0254a14 read_zero                                   189   0.3841
c0250f5c clear_user                                  217   3.3906
c0148a64 sys_write                                   251   3.9219
c0148a24 sys_read                                    268   4.1875
c014b00c __block_prepare_write                       485   0.5226
c0130dd4 unlock_page                                 493   7.7031
c0120220 current_kernel_time                         560   8.7500
c0163190 __mark_inode_dirty                          775   3.5227
c01488ec vfs_write                                   983   3.1506
c0132d9c generic_file_write                          996  10.3750
c01486fc vfs_read                                   1010   3.2372
c014b3ac __block_commit_write                       1100   7.6389
c0149500 fput                                       1110  39.6429
c01322e4 generic_file_aio_write_nolock              1558   0.6292
c0130fc0 find_lock_page                             2301  13.0739
c01495f0 fget                                       2780  33.0952
c0108ddc system_call                                4047  91.9773
c0106f64 default_idle                              24624 473.5385
00000000 total                                     45321   0.0200

UP:

c023c9ac radix_tree_lookup                            13   0.1711
c015362c inode_times_differ                           14   0.1944
c015372c inode_update_time                            14   0.1000
c012cb9c generic_file_write                           15   0.1630
c012ca90 generic_file_write_nolock                    17   0.1214
c0140e1c fget                                         17   0.3542
c023deb8 __copy_from_user_ll                          17   0.1545
c0241514 read_zero                                    17   0.0346
c014001c vfs_read                                     18   0.0682
c01401dc vfs_write                                    20   0.0758
c01430d8 generic_commit_write                         20   0.1786
c01402e4 sys_read                                     21   0.3281
c0142968 __block_commit_write                         29   0.2014
c023dc4c clear_user                                   34   0.5312
c0140324 sys_write                                    38   0.5938
c01425cc __block_prepare_write                        39   0.0422
c012c0f4 generic_file_aio_write_nolock                89   0.0362
c0108b54 system_call                                 406   9.2273
00000000 total                                       944   0.0004




^ permalink raw reply	[flat|nested] 10+ messages in thread
* Re: smp overhead, and rwlocks considered harmful
@ 2003-03-23  6:34 Adam J. Richter
  0 siblings, 0 replies; 10+ messages in thread
From: Adam J. Richter @ 2003-03-23  6:34 UTC (permalink / raw)
  To: akpm, davem, linux-kernel

On 2003-03-23, Andrew Morton wrote:
>I've been looking at the CPU cost of the write() system call.  Time how long
>it takes to write a million bytes to an ext2 file, via a million
>one-byte-writes:
[...]
>One thing is noteworthy: ia32's read_unlock() is buslocked, whereas
>spin_unlock() is not.  So let's see what happens if we convert file_lock
>from an rwlock to a spinlock:
>
>
>2.5.65-mm4, SMP:
>        0.34s user 2.00s system 100% cpu 2.329 total
>
>That's a 5% speedup.
>
>
>And if we were to convert file->f_count to be a nonatomic "int", protected by
>files_lock it would probably speed things up further.
>
>I've always been a bit skeptical about rwlocks - if you're holding the lock
>for long enough for a significant amount of reader concurrency, you're
>holding it for too long.  eg:  tasklist_lock.

	A million one byte writes is probably not the use case for
which we want to trade off, against against other cases that are more
common or more performance critical.

	I'm not saying that you're necessarily wrong.  I haven't
looked into typical rwlock usage enough to have a well founded opinion
about it, and it's obvious that you have done some detailed research
on at least this specific case.  I am saying that I think I'd have to
see essentially no negative effects on workloads that we care more
about before being convinced that converting rwlocks to spinlocks is a
good trade-off either globally or in specific cases.

	Also, what is optimal on a one CPU system running an SMP
kernel may be different from what is optimal on a bigger machine.  So,
if it turns out that you're right in the 1-2 CPU case and wrong in the
64 CPU NUMA case, then perhaps we want some maybe_rwlock primitive
that is a spinlock if one CONFIG_RWLOCK_EXPENSIVE flag is set and an
rwlock if it is not set for code that does not *rely* on the ability
to have more than one owner of a read lock.  I want to emphasize that
I'm not suggesting that anyone implement this complexity unless this
prediction turns out to be true.  I'm just speculating on one
potential scenario.

	Speaking of scaling up, I think it might be useful to have a
version of rw_semaphore and perhaps of rwlock that used per_cpu memory
(probably throgh dcounter) so that calls to read_{up,down} without any
intervening calls to write_{up,down} would cause no inter-cpu cache
consistency traffic.  (This idea was inspired by Roman Zippel's posting
of an implementation of module usage counters along these lines.)

Adam J. Richter     __     ______________   575 Oroville Road
adam@yggdrasil.com     \ /                  Milpitas, California 95035
+1 408 309-6081         | g g d r a s i l   United States of America
                         "Free Software For The Rest Of Us."

^ permalink raw reply	[flat|nested] 10+ messages in thread
end of thread, other threads:[~2003-03-23 21:40 UTC | newest]

Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2003-03-23  1:58 smp overhead, and rwlocks considered harmful Andrew Morton
2003-03-23  3:39 ` David S. Miller
2003-03-23  3:55 ` Anton Blanchard
2003-03-23  4:04   ` Andrew Morton
2003-03-23  6:25     ` Anton Blanchard
2003-03-23 12:33 ` Michael Vergoz
2003-03-23 15:17   ` Alan Cox
2003-03-23 21:43 ` Aaron Lehmann
2003-03-23 21:51   ` Andrew Morton
2003-03-23  6:34 Adam J. Richter

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®