| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Date: Fri, 24 Apr 2009 17:47:37 -0400
From: "Alan D. Brunelle" <Alan.Brunelle@...com>
To: ryov@...inux.co.jp
CC: dm-devel@...hat.com,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: [RFC PATCH dm-ioband] Added in blktrace msgs for dm-ioband
Hi Ryo -
I don't know if you are taking in patches, but whilst trying to uncover
some odd behavior I added some blktrace messages to dm-ioband-ctl.c. If
you're keeping one code base for old stuff (2.6.18-ish RHEL stuff) and
upstream you'll have to #if around these (the blktrace message stuff
came in around 2.6.26 or 27 I think).
My test case was to take a single 400GB storage device, put two 200GB
partitions on it and then see what the "penalty" or overhead for adding
dm-ioband on top. To do this I simply created an ext2 FS on each
partition in parallel (two processes each doing a mkfs to one of the
partitions). Then I put two dm-ioband devices on top of the two
partitions (setting the weight to 100 in both cases - thus they should
have equal access).
Using default values I was seeing /very/ large differences - on the
order of 3X. When I bumped the number of tokens to a large number
(10,240) the timings got much closer (<2%). I have found that using
weight-iosize performs worse than weight (closer to 5% penalty).
I'll try to formalize these results as I go forward and report out on
them. In any event, I thought I'd share this patch with you if you are
interested...
Here's a sampling from some blktrace output (sorry for the wrapping) - I
should note that I'm a bit scared to see such large numbers of holds
going on when the token count should be >5,000 for each device...
Holding these back in an equal access situation is inhibiting the block
I/O layer to merge (most) of these (as mkfs performs lots & lots of
small but sequential I/Os).
...
8,80 16 0 0.090651446 0 m N ioband 1 hold_nrm 1654
8,80 16 0 0.090653575 0 m N ioband 1 hold_nrm 1655
8,80 16 0 0.090655694 0 m N ioband 1 hold_nrm 1656
8,80 16 0 0.090657609 0 m N ioband 1 hold_nrm 1657
8,80 16 0 0.090659554 0 m N ioband 1 hold_nrm 1658
8,80 16 0 0.090661327 0 m N ioband 1 hold_nrm 1659
8,80 16 0 0.090666237 0 m N ioband 1 hold_nrm 1660
8,80 16 53036 0.090675081 4713 C W 391420657 + 1024 [0]
8,80 16 53037 0.090913365 4713 D W 392995569 + 1024
[mkfs.ext2]
8,80 16 0 0.090950380 0 m N ioband 1 add_iss 1659 1659
8,80 16 0 0.090951296 0 m N ioband 1 add_iss 1658 1658
8,80 16 0 0.090951870 0 m N ioband 1 add_iss 1657 1657
8,80 16 0 0.090952416 0 m N ioband 1 add_iss 1656 1656
8,80 16 0 0.090952965 0 m N ioband 1 add_iss 1655 1655
8,80 16 0 0.090953517 0 m N ioband 1 add_iss 1654 1654
8,80 16 0 0.090954064 0 m N ioband 1 add_iss 1653 1653
8,80 16 0 0.090954610 0 m N ioband 1 add_iss 1652 1652
8,80 16 0 0.090955280 0 m N ioband 1 add_iss 1651 1651
8,80 16 0 0.090956495 0 m N ioband 1 pop_iss
8,80 16 53038 0.090957387 4659 A WS 396655745 + 8 <- (8,82)
6030744
8,80 16 53039 0.090957561 4659 Q WS 396655745 + 8 [kioband/16]
8,80 16 53040 0.090958328 4659 M WS 396655745 + 8 [kioband/16]
8,80 16 0 0.090959595 0 m N ioband 1 pop_iss
8,80 16 53041 0.090959754 4659 A WS 396655753 + 8 <- (8,82)
6030752
8,80 16 53042 0.090960007 4659 Q WS 396655753 + 8 [kioband/16]
8,80 16 53043 0.090960402 4659 M WS 396655753 + 8 [kioband/16]
8,80 16 0 0.090960962 0 m N ioband 1 pop_iss
8,80 16 53044 0.090961104 4659 A WS 396655761 + 8 <- (8,82)
6030760
8,80 16 53045 0.090961231 4659 Q WS 396655761 + 8 [kioband/16]
8,80 16 53046 0.090961496 4659 M WS 396655761 + 8 [kioband/16]
8,80 16 0 0.090961995 0 m N ioband 1 pop_iss
8,80 16 53047 0.090962117 4659 A WS 396655769 + 8 <- (8,82)
6030768
8,80 16 53048 0.090962222 4659 Q WS 396655769 + 8 [kioband/16]
8,80 16 53049 0.090962530 4659 M WS 396655769 + 8 [kioband/16]
8,80 16 0 0.090962974 0 m N ioband 1 pop_iss
8,80 16 53050 0.090963095 4659 A WS 396655777 + 8 <- (8,82)
6030776
8,80 16 53051 0.090963334 4659 Q WS 396655777 + 8 [kioband/16]
8,80 16 53052 0.090963518 4659 M WS 396655777 + 8 [kioband/16]
8,80 16 0 0.090963985 0 m N ioband 1 pop_iss
8,80 16 53053 0.090964220 4659 A WS 396655785 + 8 <- (8,82)
6030784
8,80 16 53054 0.090964327 4659 Q WS 396655785 + 8 [kioband/16]
8,80 16 53055 0.090964632 4659 M WS 396655785 + 8 [kioband/16]
8,80 16 0 0.090965094 0 m N ioband 1 pop_iss
8,80 16 53056 0.090965218 4659 A WS 396655793 + 8 <- (8,82)
6030792
8,80 16 53057 0.090965324 4659 Q WS 396655793 + 8 [kioband/16]
8,80 16 53058 0.090965548 4659 M WS 396655793 + 8 [kioband/16]
8,80 16 0 0.090965991 0 m N ioband 1 pop_iss
8,80 16 53059 0.090966112 4659 A WS 396655801 + 8 <- (8,82)
6030800
8,80 16 53060 0.090966221 4659 Q WS 396655801 + 8 [kioband/16]
8,80 16 53061 0.090966526 4659 M WS 396655801 + 8 [kioband/16]
8,80 16 0 0.090966944 0 m N ioband 1 pop_iss
8,80 16 53062 0.090967065 4659 A WS 396655809 + 8 <- (8,82)
6030808
8,80 16 53063 0.090967173 4659 Q WS 396655809 + 8 [kioband/16]
8,80 16 53064 0.090967383 4659 M WS 396655809 + 8 [kioband/16]
8,80 16 0 0.090968394 0 m N ioband 1 add_iss 1650 1650
8,80 16 0 0.090969068 0 m N ioband 1 add_iss 1649 1649
8,80 16 0 0.090969684 0 m N ioband 1 add_iss 1648 1648
...
Regards,
Alan D. Brunelle
Hewlett-Packard
View attachment "0001-Added-in-blktrace-msgs-for-dm-ioband.patch" of type "text/x-diff" (3656 bytes)
Powered by blists - more mailing lists