Sagi,
Here is an example of the different types of tests. This was only on one kernel.
The first two are to set a baseline. The lines starting with buffer is
using fio with direct=0, the lines starting with direct is fio with
direct=1. The lines starting with block is fio running against a raw
Sagi,
Yes you are understanding the data correctly and what I'm seeing. I
think you are also seeing the confusion that I've been running into
trying to figure this out as well. As far as your questions about SRP,
the performance data is from the initiator and the CPU info is from
the target (all
Let me see if I get this correct:
4.5.0_rc3_1aaa57f5_00399
sdc;10.218.128.17;4627942;1156985;18126
sdf;10.218.202.17;4590963;1147740;18272
sdk;10.218.203.17;4564980;1141245;18376
sdn;10.218.204.17;4571946;1142986;18348
sdd;10.219.128.17;4591717;1147929;18269
There is no need to be concerned about srpt crashing in the latest
kernel. Srpt only crashed when I was testing kernels in that change
set (7861728..5e47f19) that I identified the 10-15% performance drop
in iSER between the 4.5 and 4.6 kernel. My tests from the 4.6 to
4.7rc3 didn't have a problem
- Original Message -
> From: "Bart Van Assche"
> To: "Robert LeBlanc" , "Sagi Grimberg"
>
> Cc: linux-r...@vger.kernel.org, linux-scsi@vger.kernel.org, "Max Gurtovoy"
>
> Sent: Wednesday, June
Sagi & Max,
Here is the results of SRP using the same ramdisk backstore that I was
using from iSER (as same as can be between reboots and restoring
targetcli config). I also tested the commit before 9679cc51eb13
(5adabdd122e471fe978d49471624bab08b5373a7) which is included here. I'm
not seeing a
On 06/21/2016 10:26 PM, Robert LeBlanc wrote:
Srpt keeps crashing couldn't test
If this is reproducible with the latest rc kernel or with any of the
stable kernels please report this in a separate e-mail, together with
the crash call stack and information about how to reproduce this.
Sagi & Max,
Here is the results of SRP using the same ramdisk backstore that I was
using from iSER (as same as can be between reboots and restoring
targetcli config). I also tested the commit before 9679cc51eb13
(5adabdd122e471fe978d49471624bab08b5373a7) which is included here. I'm
not seeing a
Sagi,
I'm working to implement SRP (I think I got it all working) to test
some of the commits. I can try TGT afterwards and the commit you
mention. I haven't been watching the CPU lately, but before when I was
doing a lot of testing, there wasn't any one thread that was at 100%.
There are several
Hey Robert,
I narrowed the performance degradation to this series
7861728..5e47f19, but while trying to bisect it, the changes were
erratic between each commit that I could not figure out exactly which
introduced the issue. If someone could give me some pointers on what
to do, I can keep trying
Did you see this kind of regression in SRP ? or with some other target
(e.g TGT) ?
Trying to understand if it's a ULP issue or LLD...
On 6/20/2016 6:23 PM, Robert LeBlanc wrote:
Adding linux-scsi
This last week I tried to figure out where a 10-15% decrease in
performance showed up between 4.5
I can test with SRP and report back what I find (haven't used SRP in
years so I'll need to brush up on it).
Robert LeBlanc
PGP Fingerprint 79A2 9CA4 6CC4 45DD A904 C70E E654 3BB2 FA62 B9F1
On Mon, Jun 20, 2016 at 3:27 PM, Max Gurtovoy wrote:
> Did you see
Adding linux-scsi
This last week I tried to figure out where a 10-15% decrease in
performance showed up between 4.5 and 4.6 using iSER and ConnectX-3
and Connect-IB cards (10.{218,219}.*.17 are Connect-IB and 10.220.*.17
are ConnectX-3). To review, straight RDMA transfers between cards
showed
13 matches
Mail list logo