Re: Connect-IB not performing as well as ConnectX-3 with iSER

[Bart Van Assche]

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.


Thanks,

Bart.
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2] byteswap: try to avoid __builtin_constant_p gcc bug

[Tomas Winkler]

On Tue, Jun 21, 2016 at 12:02 PM, Tomas Winkler  wrote:
> On Tue, May 3, 2016 at 9:36 AM, Arnd Bergmann  wrote:
>> On Monday 02 May 2016 16:32:25 Andrew Morton wrote:
>>> On Tue, 03 May 2016 01:10:16 +0200 Arnd Bergmann  wrote:
>>>
>>> > On Monday 02 May 2016 16:02:18 Andrew Morton wrote:
>>> > > On Mon, 02 May 2016 23:48:19 +0200 Arnd Bergmann  wrote:
>>> > >
>>> > > > This is another attempt to avoid a regression in wwn_to_u64() after
>>> > > > that started using get_unaligned_be64(), which in turn ran into a
>>> > > > bug on gcc-4.9 through 6.1.
>>> > >
>>> > > I'm still getting a couple screenfuls of things like
>>> > >
>>> > > net/tipc/name_distr.c: In function 'tipc_named_process_backlog':
>>> > > net/tipc/name_distr.c:330: warning: format '%u' expects type 'unsigned 
>>> > > int', but argument 3 has type 'unsigned int'
>>> > > net/tipc/name_distr.c:330: warning: format '%u' expects type 'unsigned 
>>> > > int', but argument 4 has type 'unsigned int'
>>> > > net/tipc/name_distr.c:330: warning: format '%u' expects type 'unsigned 
>>> > > int', but argument 5 has type 'unsigned int'
>>> > > net/tipc/name_distr.c:330: warning: format '%u' expects type 'unsigned 
>>> > > int', but argument 7 has type 'unsigned int'
>>> >
>>> > I've built a few thousand kernels (arm32 with gcc-6.1) with the patch 
>>> > applied,
>>> > but didn't see this one. What target architecture and compiler version 
>>> > produced
>>> > this? Does it go away if you add a (__u32) cast? I don't even know what 
>>> > the
>>> > warning is trying to tell me.
>>>
>>> heh, I didn't actually read it.
>>>
>>> Hopefully we can write this off as a gcc-4.4.4 glitch. 4.8.4 is OK.
>>
>> Ah, old compiler. I've tried gcc-4.3 now on ARM, and I don't get this warning
>> (just a lot "may be used uninitialized"), but unlike gcc-4.4, my version 
>> doesn't
>> actually get into the code path I have changed because __builtin_bswap32 was 
>> only
>> introduced with 4.4.
>>
>> I don't have gcc-4.4 and 4.5 here, but the warning does show up with 4.6, 4.7
>> and 4.8:
>>
>> drivers/soc/sunxi/sunxi_sram.c: In function ‘sunxi_sram_show’:
>> drivers/soc/sunxi/sunxi_sram.c:103:7: warning: format ‘%x’ expects argument 
>> of type ‘unsigned int’, but argument 3 has type ‘unsigned int’ [-Wformat=]
>>
>> 4.8 is probably still common enough that we should try to address this.
>> This change addresses the problem for me with ARM gcc-4.8, but adding
>> two more type casts. This also makes the 16/32/64 bit swaps all
>> look the same. I would expect this to also have the same effect on 4.4.
>>
>> Please fold into the previous patch.
>>
>> Signed-off-by: Arnd Bergmann 
>>
>> diff --git a/include/uapi/linux/swab.h b/include/uapi/linux/swab.h
>> index d737804af181..8f3a8f606fd9 100644
>> --- a/include/uapi/linux/swab.h
>> +++ b/include/uapi/linux/swab.h
>> @@ -97,7 +97,7 @@ static inline __attribute_const__ __u32 __fswahb32(__u32 
>> val)
>>   * @x: value to byteswap
>>   */
>>  #ifdef __HAVE_BUILTIN_BSWAP16__
>> -#define __swab16(x) __builtin_bswap16((__u16)(x))
>> +#define __swab16(x) (__u16)__builtin_bswap16((__u16)(x))
>>  #else
>>  #define __swab16(x)\
>> (__builtin_constant_p((__u16)(x)) ? \
>> @@ -110,7 +110,7 @@ static inline __attribute_const__ __u32 __fswahb32(__u32 
>> val)
>>   * @x: value to byteswap
>>   */
>>  #ifdef __HAVE_BUILTIN_BSWAP32__
>> -#define __swab32(x) __builtin_bswap32((__u32)(x))
>> +#define __swab32(x) (__u32)__builtin_bswap32((__u32)(x))
>>  #else
>>  #define __swab32(x)\
>> (__builtin_constant_p((__u32)(x)) ? \
>
>>
>
> I wonder if this doesn't break switch statement that requires a
> constant expression, there few cases like this over the kernel.
>
> switch(val) {
> case cpu_to_le32(IXGBE_RXDADV_STAT_FCSTAT_FCPRSP):
>
> http://lxr.free-electrons.com/source/drivers/net/ethernet/intel/ixgbe/ixgbe_fcoe.c#L458
>

I'm asking because sparse and checkpatch doesn't agree on that ping
sparse issues
'error: bad constant expression'
When changing to __constant_cpu_to_le32 sparse is happy but
checkpatch.ps is complaining
__constant_cpu_to_le32 should be cpu_to_le32



 Thanks
 Tomas
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Connect-IB not performing as well as ConnectX-3 with iSER

[Sagi Grimberg]

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 correlation between iSER and SRP that would lead me to
believe that the changes are happening in both implementations.

Does this provide enough information for you, or do you think TGT will
be needed?


I'm a little lost on which test belongs to what, can you specify that
more clearly?



4.4 (afd2ff9) vanilla default config
sdb;10.218.128.17;5150176;1287544;16288
sdd;10.218.202.17;5092337;1273084;16473
sdh;10.218.203.17;5129078;1282269;16355
sdk;10.218.204.17;5129078;1282269;16355
sdg;10.219.128.17;5155874;1288968;16270
sdf;10.219.202.17;5131588;1282897;16347
sdi;10.219.203.17;5165399;1291349;16240
sdl;10.219.204.17;5157459;1289364;16265
sdc;10.220.128.17;3684223;921055;22769
sde;10.220.202.17;3692169;923042;22720
sdj;10.220.203.17;3699170;924792;22677
Sdm;10.220.204.17;3697865;924466;22685

mlx5_0;sde;2968368;742092;28260
mlx4_0;sdd;3325645;831411;25224
mlx5_0;sdc;3023466;755866;27745

4.4.0_rc2_3e27c920
sdc;10.218.128.17;5291495;1322873;15853
sde;10.218.202.17;4966024;1241506;16892
sdh;10.218.203.17;4980471;1245117;16843
sdk;10.218.204.17;4966612;1241653;16890
sdd;10.219.128.17;5060084;1265021;16578
sdf;10.219.202.17;5065278;1266319;16561
sdi;10.219.203.17;5047600;1261900;16619
sdl;10.219.204.17;5036992;1259248;16654
sdn;10.220.128.17;3775081;943770;1
sdg;10.220.202.17;3758336;939584;22320
sdj;10.220.203.17;3792832;948208;22117
Sdm;10.220.204.17;3771516;942879;22242

Mlx4_0;sde;4648715;1162178;18045  ~73% cpu ib_srpt_compl
Mlx5_0;sdd;3476566;869141;24129 ~80% cpu ib_srpt_compl
mlx5_0;sdc;3492343;873085;24020

4.4.0_rc2_ab46db0a
sdc;10.218.128.17;3792146;948036;22121
sdf;10.218.202.17;3738405;934601;22439
sdj;10.218.203.17;3764239;941059;22285
sdl;10.218.204.17;3785302;946325;22161
sdd;10.219.128.17;3762382;940595;22296
sdg;10.219.202.17;3765760;941440;22276
sdi;10.219.203.17;3873751;968437;21655
sdm;10.219.204.17;3769483;942370;22254
sde;10.220.128.17;5022517;1255629;16702
sdh;10.220.202.17;5018911;1254727;16714
sdk;10.220.203.17;5037295;1259323;16653
Sdn;10.220.204.17;5033064;1258266;16667

mlx4_0;sde;4635358;1158839;18097
mlx5_0;sdd;3459077;864769;24251
mlx5_0;sdc;3465650;866412;24205

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
sdi;10.219.202.17;4505644;1126411;18618
sdg;10.219.203.17;4562001;1140500;18388
sdl;10.219.204.17;4583187;1145796;18303
sde;10.220.128.17;5511568;1377892;15220
sdh;10.220.202.17;551;137;15209
sdj;10.220.203.17;5609983;1402495;14953
sdm;10.220.204.17;5509035;1377258;15227

Mlx5_0;sde;3593013;898253;23347 100% CPU kworker/u69:2
Mlx5_0;sdd;3588555;897138;23376 100% CPU kworker/u69:2
Mlx4_0;sdc;3525662;881415;23793 100% CPU kworker/u68:0

4.5.0_rc5_7861728d_1
sdc;10.218.128.17;3747591;936897;22384
sdf;10.218.202.17;3750607;937651;22366
sdh;10.218.203.17;3750439;937609;22367
sdn;10.218.204.17;3771008;942752;22245
sde;10.219.128.17;3867678;966919;21689
sdg;10.219.202.17;3781889;945472;22181
sdk;10.219.203.17;3791804;947951;22123
sdl;10.219.204.17;3795406;948851;22102
sdd;10.220.128.17;5039110;1259777;16647
sdi;10.220.202.17;4992921;1248230;16801
sdj;10.220.203.17;5015610;1253902;16725
Sdm;10.220.204.17;5087087;1271771;16490

Mlx5_0;sde;2930722;732680;28623 ~98% CPU kworker/u69:0
Mlx5_0;sdd;2910891;727722;28818 ~98% CPU kworker/u69:0
Mlx4_0;sdc;3263668;815917;25703 ~98% CPU kworker/u68:0

4.5.0_rc5_f81bf458_00018
sdb;10.218.128.17;5023720;1255930;16698
sde;10.218.202.17;5016809;1254202;16721
sdj;10.218.203.17;5021915;1255478;16704
sdk;10.218.204.17;5021314;1255328;16706
sdc;10.219.128.17;4984318;1246079;16830
sdf;10.219.202.17;4986096;1246524;16824
sdh;10.219.203.17;5043958;1260989;16631
sdm;10.219.204.17;5032460;1258115;16669
sdd;10.220.128.17;3736740;934185;22449
sdg;10.220.202.17;3728767;932191;22497
sdi;10.220.203.17;3752117;938029;22357
Sdl;10.220.204.17;3763901;940975;22287

Srpt keeps crashing couldn't test

4.5.0_rc5_5adabdd1_00023
Sdc;10.218.128.17;3726448;931612;22511 ~97% CPU kworker/u69:4
sdf;10.218.202.17;3750271;937567;22368
sdi;10.218.203.17;3749266;937316;22374
sdj;10.218.204.17;3798844;949711;22082
sde;10.219.128.17;3759852;939963;22311 ~97% CPU kworker/u69:4
sdg;10.219.202.17;3772534;943133;22236
sdl;10.219.203.17;3769483;942370;22254
sdn;10.219.204.17;3790604;947651;22130
sdd;10.220.128.17;5171130;1292782;16222 ~96% CPU kworker/u68:3
sdh;10.220.202.17;5105354;1276338;16431
sdk;10.220.203.17;4995300;1248825;16793
sdm;10.220.204.17;4959564;1239891;16914

Srpt crashes

4.5.0_rc5_07b63196_00027
sdb;10.218.128.17;3606142;901535;23262
sdg;10.218.202.17;3570988;892747;23491
sdf;10.218

Re: [PATCH v2] byteswap: try to avoid __builtin_constant_p gcc bug

[Arnd Bergmann]

On Wednesday, June 22, 2016 11:24:50 AM CEST Tomas Winkler wrote:
> On Tue, Jun 21, 2016 at 12:02 PM, Tomas Winkler  wrote:
> > On Tue, May 3, 2016 at 9:36 AM, Arnd Bergmann  wrote:
> >> On Monday 02 May 2016 16:32:25 Andrew Morton wrote:

> >>  #ifdef __HAVE_BUILTIN_BSWAP32__
> >> -#define __swab32(x) __builtin_bswap32((__u32)(x))
> >> +#define __swab32(x) (__u32)__builtin_bswap32((__u32)(x))
> >>  #else
> >>  #define __swab32(x)\
> >> (__builtin_constant_p((__u32)(x)) ? \
> >
> >>
> >
> > I wonder if this doesn't break switch statement that requires a
> > constant expression, there few cases like this over the kernel.
> >
> > switch(val) {
> > case cpu_to_le32(IXGBE_RXDADV_STAT_FCSTAT_FCPRSP):
> >
> > http://lxr.free-electrons.com/source/drivers/net/ethernet/intel/ixgbe/ixgbe_fcoe.c#L458
> >
> 
> I'm asking because sparse and checkpatch doesn't agree on that ping
> sparse issues
> 'error: bad constant expression'
> When changing to __constant_cpu_to_le32 sparse is happy but
> checkpatch.ps is complaining
> __constant_cpu_to_le32 should be cpu_to_le32
> 

That is an interesting problem, as both seem to be reasonable:
sparse probably doesn't understand __builtin_constant_p() enough,
while avoiding __constant_cpu_to_le32() is a good recommendation
in general.

How many instances of this do you see in the kernel? If ixgbe is the
only one, I'd just move the byteswap up into the switch statement:

switch (le32_to_cpu(val)) {
case IXGBE_RXDADV_STAT_FCSTAT_FCPRSP:

which may cost one or two cycles for the non-constant byteswap,
but is also easier to read than the current code.

Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [PATCH v2] byteswap: try to avoid __builtin_constant_p gcc bug

[Levy, Amir (Jer)]

On 2016-06-22 Arnd Bergmann wrote:
> On Wednesday, June 22, 2016 11:24:50 AM CEST Tomas Winkler wrote:
> > On Tue, Jun 21, 2016 at 12:02 PM, Tomas Winkler 
> wrote:
> > > On Tue, May 3, 2016 at 9:36 AM, Arnd Bergmann 
> wrote:
> > >> On Monday 02 May 2016 16:32:25 Andrew Morton wrote:
> 
> > >>  #ifdef __HAVE_BUILTIN_BSWAP32__
> > >> -#define __swab32(x) __builtin_bswap32((__u32)(x))
> > >> +#define __swab32(x) (__u32)__builtin_bswap32((__u32)(x))
> > >>  #else
> > >>  #define __swab32(x)\
> > >> (__builtin_constant_p((__u32)(x)) ? \
> > >
> > >>
> > >
> > > I wonder if this doesn't break switch statement that requires a
> > > constant expression, there few cases like this over the kernel.
> > >
> > > switch(val) {
> > > case cpu_to_le32(IXGBE_RXDADV_STAT_FCSTAT_FCPRSP):
> > >
> > > http://lxr.free-electrons.com/source/drivers/net/ethernet/intel/ixgb
> > > e/ixgbe_fcoe.c#L458
> > >
> >
> > I'm asking because sparse and checkpatch doesn't agree on that ping
> > sparse issues
> > 'error: bad constant expression'
> > When changing to __constant_cpu_to_le32 sparse is happy but
> > checkpatch.ps is complaining
> > __constant_cpu_to_le32 should be cpu_to_le32
> >
> 
> That is an interesting problem, as both seem to be reasonable:
> sparse probably doesn't understand __builtin_constant_p() enough, while
> avoiding __constant_cpu_to_le32() is a good recommendation in general.
> 
> How many instances of this do you see in the kernel? If ixgbe is the only one,
> I'd just move the byteswap up into the switch statement:
> 
>   switch (le32_to_cpu(val)) {
>   case IXGBE_RXDADV_STAT_FCSTAT_FCPRSP:
> 
> which may cost one or two cycles for the non-constant byteswap, but is also
> easier to read than the current code.
> 
>   Arnd

There are more than 20 files that have the statement: case cpu_to_...
Sparse complains about: case __builtin_bswap, not about __builtin_constant_p.

Amir

--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2] byteswap: try to avoid __builtin_constant_p gcc bug

[Tomas Winkler]

On Wed, Jun 22, 2016 at 1:25 PM, Levy, Amir (Jer)
 wrote:
> On 2016-06-22 Arnd Bergmann wrote:
>> On Wednesday, June 22, 2016 11:24:50 AM CEST Tomas Winkler wrote:
>> > On Tue, Jun 21, 2016 at 12:02 PM, Tomas Winkler 
>> wrote:
>> > > On Tue, May 3, 2016 at 9:36 AM, Arnd Bergmann 
>> wrote:
>> > >> On Monday 02 May 2016 16:32:25 Andrew Morton wrote:
>>
>> > >>  #ifdef __HAVE_BUILTIN_BSWAP32__
>> > >> -#define __swab32(x) __builtin_bswap32((__u32)(x))
>> > >> +#define __swab32(x) (__u32)__builtin_bswap32((__u32)(x))
>> > >>  #else
>> > >>  #define __swab32(x)\
>> > >> (__builtin_constant_p((__u32)(x)) ? \
>> > >
>> > >>
>> > >
>> > > I wonder if this doesn't break switch statement that requires a
>> > > constant expression, there few cases like this over the kernel.
>> > >
>> > > switch(val) {
>> > > case cpu_to_le32(IXGBE_RXDADV_STAT_FCSTAT_FCPRSP):
>> > >
>> > > http://lxr.free-electrons.com/source/drivers/net/ethernet/intel/ixgb
>> > > e/ixgbe_fcoe.c#L458
>> > >
>> >
>> > I'm asking because sparse and checkpatch doesn't agree on that ping
>> > sparse issues
>> > 'error: bad constant expression'
>> > When changing to __constant_cpu_to_le32 sparse is happy but
>> > checkpatch.ps is complaining
>> > __constant_cpu_to_le32 should be cpu_to_le32
>> >
>>
>> That is an interesting problem, as both seem to be reasonable:
>> sparse probably doesn't understand __builtin_constant_p() enough, while
>> avoiding __constant_cpu_to_le32() is a good recommendation in general.
>>
>> How many instances of this do you see in the kernel? If ixgbe is the only 
>> one,
>> I'd just move the byteswap up into the switch statement:
>>
>>   switch (le32_to_cpu(val)) {
>>   case IXGBE_RXDADV_STAT_FCSTAT_FCPRSP:
>>
>> which may cost one or two cycles for the non-constant byteswap, but is also
>> easier to read than the current code.
>>
>>   Arnd
>
> There are more than 20 files that have the statement: case cpu_to_...
> Sparse complains about: case __builtin_bswap, not about __builtin_constant_p.

There is even much more in the header files used in  initializers,
which also require constants.  I wonder if __builtin_bswap produces
constant expression correctly under gcc?

Thanks
Tomas
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: parisc late boot crash in 4.4-rc, scsi-related

[Meelis Roos]

> > > > I noticed on RP3440 and A500 that recent 4.4-rc* crashes on boot.
> > > >
> > > >I've not seen it with 4.4-rc yet, but I've seen it on debian kernel
> > > >4.3.3:
> > This is still present in 4.6, just tested. All my pariscs are broken
> > - A500, RP3410, RP3440. 4.3 is the latest working release for me. If
> > 4.3.3 is broken, it might be possible to bisect more easily.
> 
> I believe this is fixed in current gcc versions (4.9 and latter). It was
> exposed by a blk-merge
> change.  It was fixed by this change:

Out of interest, how do other parisc users get the new compiler?

What distro are you using?

My pariscs are gentoo and still only the old versions are available on 
hppa.

-- 
Meelis Roos (mr...@linux.ee)
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: parisc late boot crash in 4.4-rc, scsi-related

[John David Anglin]

On 2016-06-22, at 7:52 AM, Meelis Roos wrote:

> I noticed on RP3440 and A500 that recent 4.4-rc* crashes on boot.
> 
> I've not seen it with 4.4-rc yet, but I've seen it on debian kernel
> 4.3.3:
>>> This is still present in 4.6, just tested. All my pariscs are broken
>>> - A500, RP3410, RP3440. 4.3 is the latest working release for me. If
>>> 4.3.3 is broken, it might be possible to bisect more easily.
>> 
>> I believe this is fixed in current gcc versions (4.9 and latter). It was
>> exposed by a blk-merge
>> change.  It was fixed by this change:
> 
> Out of interest, how do other parisc users get the new compiler?

The Debian binaries have the change.

For development, I get gcc with svn from .  It is also 
possible to
use git to access the sources.

gcc -v should show how your current compiler was built.

> 
> What distro are you using?

We are using Debian unstable.  Helge and myself have setup an automated build 
system
with several buildds.  We are getting reasonable support from package 
maintainers.

Approximately, 11100 packages are available using apt-get:
https://buildd.debian.org/status/architecture.php?a=hppa&suite=sid
In terms of package counts, we are about equal to alpha, ppc64 and sparc64.

Helge has setup a Debian install disk.  Info on this is here:
https://parisc.wiki.kernel.org/index.php/Main_Page

> 
> My pariscs are gentoo and still only the old versions are available on 
> hppa.


Hope this helps,
Dave
--
John David Anglin   dave.ang...@bell.net



--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2] byteswap: try to avoid __builtin_constant_p gcc bug

[Arnd Bergmann]

On Wednesday, June 22, 2016 2:44:21 PM CEST Tomas Winkler wrote:
> >
> > There are more than 20 files that have the statement: case cpu_to_...
> > Sparse complains about: case __builtin_bswap, not about 
> > __builtin_constant_p.
> 
> There is even much more in the header files used in  initializers,
> which also require constants.  I wonder if __builtin_bswap produces
> constant expression correctly under gcc?

In gcc-4.8 or later yes. gcc-4.6/4.7 on powerpc was a special case that we
have worked around now, as the 16-bit byteswap there was not a constant
expression, unlike the 32-bit and 64-bit ones.

Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/2] lpfc: support for CPU phys_id and core_id on PowerPC64

[Mauricio Faria de Oliveira]

Hi Martin,

On 06/21/2016 11:16 PM, Martin K. Petersen wrote:

Distros are free to carry a patch such as yours. That puts the burden on
them and not on upstream which is going in a different direction as
outlined by Christoph.



This is ultimately Broadcom's decision. It is their driver.


Right, I understand.  I submitted the patch in case they see value in
having it upstream, as some distros discuss/ask about what's the status
(or differences to) upstream.

In some cases, a rationale like this one being documented on a mailing
list is sufficient, provided the patch hasn't received other technical
problems, for example.

Thanks for the review/comments (Christoph too),

--
Mauricio Faria de Oliveira
IBM Linux Technology Center

--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] target/iblock: use ilog2 to compute block size

[Arnd Bergmann]

Enabling CONFIG_UBSAN_SANITIZE_ALL on ARM caused a link error:

drivers/target/built-in.o: In function 
`iblock_emulate_read_cap_with_block_size.constprop.1':
target_core_iblock.c:(.text+0xc2774): undefined reference to `ilog2_NaN'
target_core_iblock.c:(.text+0xc27f8): undefined reference to `__aeabi_uldivmod'
target_core_iblock.c:(.text+0xc299c): undefined reference to `__aeabi_uldivmod'

This is caused by gcc not behaving in the expected ways with 
__builtin_constant_p(),
but it also points to somewhat inefficient code: As we know that the
block size is a power-of-two value, we can turn the expensive 64-bit
division into a simpler variable bit shift.

Signed-off-by: Arnd Bergmann 
---
 drivers/target/target_core_iblock.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/target/target_core_iblock.c 
b/drivers/target/target_core_iblock.c
index 22af12f8b8eb..3ab4e2d1202c 100644
--- a/drivers/target/target_core_iblock.c
+++ b/drivers/target/target_core_iblock.c
@@ -201,9 +201,9 @@ static unsigned long long 
iblock_emulate_read_cap_with_block_size(
struct block_device *bd,
struct request_queue *q)
 {
-   unsigned long long blocks_long = (div_u64(i_size_read(bd->bd_inode),
-   bdev_logical_block_size(bd)) - 1);
u32 block_size = bdev_logical_block_size(bd);
+   unsigned int block_shift = ilog2(block_size);
+   unsigned long long blocks_long = (i_size_read(bd->bd_inode) >> 
block_shift) - 1;
 
if (block_size == dev->dev_attrib.block_size)
return blocks_long;
-- 
2.9.0

--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Connect-IB not performing as well as ConnectX-3 with iSER

[Laurence Oberman]

- 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 22, 2016 4:18:31 AM
> Subject: Re: Connect-IB not performing as well as ConnectX-3 with iSER
> 
> 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.
> 
> Thanks,
> 
> Bart.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
Robert

I am exercising the ib_srpt configured vi a targetlio very heavily in 4.7.0-rc1.
I have no crashes or issues.
I also had 4.5 running ib_srpt with no crashes, although I had some other 
timeouts etc depending on the load.

What sort of crashes are you talking about ?
Does the system crash, ib_srpt dump stack ?

Thanks
Laurence
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/3] scsi: disable VPD page check on error

[Christoph Hellwig]

On Mon, Jun 20, 2016 at 08:57:47AM +0200, Hannes Reinecke wrote:
> If we encounter an error during initial VPD page scan we should be
> setting the 'skip_vpd_pages' bit to avoid further accesses.
> Any errors during rescan should be ignored, as we might encounter
> temporary I/O errors during rescan.

Looks fine in general, but why disable this for a rescan?  Doing
the check there as well at least doesn't seem harmful, and for the
unlikely case of a botched firmware upgrade it might even be useful.
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 3/3] scsi: consolidate checking for VPD pages

[Christoph Hellwig]

Looks fine, although I wonder if simple calling scsi_device_supports_vpd
in scsi_get_vpd_page wouldn't be even better.
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/5] scsi: make scsi_eh_scmd_add() always succeed

[Christoph Hellwig]

Agreed, I think trying to handle these sorts of errors isn't going
to be helpful, while the WARN_ON at least gives us a chance to
diagnose the issue if it ever happened.

> + WARN_ON(!shost->ehandler);
>  
>   spin_lock_irqsave(shost->host_lock, flags);
> + WARN_ON(shost->shost_state != SHOST_RUNNING &&
> + shost->shost_state != SHOST_CANCEL &&
> + shost->shost_state != SHOST_RECOVERY &&
> + shost->shost_state != SHOST_CANCEL_RECOVERY);

Use WARN_ON_ONCE to avoid repeated backtraces for the same condition.

>   if (scsi_host_set_state(shost, SHOST_RECOVERY))
> - if (scsi_host_set_state(shost, SHOST_CANCEL_RECOVERY))
> - goto out_unlock;
> + scsi_host_set_state(shost, SHOST_CANCEL_RECOVERY);

No warn_on or early return here?
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/3] scsi: Move 'scsi_attach_vpd()' prototype to scsi_priv.h

[Christoph Hellwig]

Looks fine,

Reviewed-by: Christoph Hellwig 
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 4/5] scsi: make asynchronous aborts mandatory

[Christoph Hellwig]

Looks fine and probably should move toward the beginning of
the series:

Reviewed-by: Christoph Hellwig 
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 3/5] scsi: make eh_eflags persistent

[Christoph Hellwig]

On Mon, Jun 20, 2016 at 11:35:38AM +0200, Hannes Reinecke wrote:
> To detect if a failed command has been retried we must not
> clear scmd->eh_eflags when EH finishes.
> The flag should be persistent throughout the lifetime
> of the command.

Please explain what issue this solves - the behavior has been there
for a while and even documented, so explaining how this was wrong
would be very useful.
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 5/5] scsi: Do not escalate failed EH command

[Christoph Hellwig]

On Mon, Jun 20, 2016 at 11:35:40AM +0200, Hannes Reinecke wrote:
> If an EH command fails there is no need to escalate; we are already
> in EH and the escalation will start anyway.

I agree with this in principle, but is this really the case for all
callers?

E.g. the call to scsi_request_sense in scsi_eh_get_sense simply
skips to the next cmd on failure.  This could use a little more
description explaining how all callers of this are indeed fine
with not escalating manually.
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] target/iblock: use ilog2 to compute block size

[Christoph Hellwig]

This doesn't compute the block size, it computes the number of block
in a block device.  I think it would be useful to add a generic helper
(e.g. in blkdev.h) as this calculation seems to be open coded in various
places.
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 19/24] fnic: Use time64_t to represent trace timestamps

[Arnd Bergmann]

On Sunday, June 19, 2016 5:27:18 PM CEST Deepa Dinamani wrote:
> trace timestamps use struct timespec and CURRENT_TIME which
> are not y2038 safe.
> These timestamps are only part of the trace log on the machine
> and are not shared with the fnic.
> Replace then with y2038 safe struct timespec64 and
> ktime_get_real_ts64(), respectively.
> 
> Note that change to add time64_to_tm() is already part of John's
> kernel tree: https://lkml.org/lkml/2016/6/17/875 .
> 

While the patch looks good, I think it can't be part of this
series now, since it has to go on top of that first patch,
rather than merged in parallel.

When you send a pull request, please leave it out and submit
this one separately after 4.8-rc1.

Arnd

--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Connect-IB not performing as well as ConnectX-3 with iSER

[Robert LeBlanc]

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 with srpt crashing.

The format of the output is as follows:

Kernel_tag_commit
iSER tests with results in this format
 (last
three fields are fields 7,8,9 from fio)
i.e. sdc;10.218.128.17;3260244;815061;25730
SRP LIO tests

i.e. mlx5_0;sdd;2986864;746716;28085

This is repeated for each kernel tested. On some tests I also
documented the observed CPU utilization of some of the target
processes. In some cases I was lazy and if the information was the
same for both mlx5 targets, I didn't duplicate it. For iSER, there are
four aliases on each adapter to provide four paths for each IB port
(this is a remnant of some previous multipathing tests, and now only
serves as providing additional data points to know how repeatable the
tests are). 10.218.*.17 and 10.219.*.17 are generally on the mlx5
ports while 19.220.*.17 are on the mlx4 port (some tests had the
adapters swapped, but none of these did and it is easy to identify
them by the grouping).

This test was performed against each path individually. I created an
ext4 filesystem on the device (no partitions), then would mount the
file system on one path, run the test, umount the path, mount the next
path, run the test, etc so that there is no multipathing confusing the
tests. I also am _NOT_ running the tests on all paths at the same time
using fio.

The fio command I'm using is: fio --rw=read --bs=4K --size=2G
--numjobs=40 --name=worker.matt --group_reporting --minimal |  cut
-d';' -f7,8,9

I hope that clears up the confusion, if not, please ask for more clarification.

On Jun 22, 2016 2:18 AM, "Bart Van Assche"  wrote:
>
> 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.
>
> Thanks,
>
> Bart.
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [Y2038] [PATCH v2 00/24] Delete CURRENT_TIME and CURRENT_TIME_SEC macros

[Arnd Bergmann]

On Sunday, June 19, 2016 5:26:59 PM CEST Deepa Dinamani wrote:
> The series is aimed at getting rid of CURRENT_TIME and CURRENT_TIME_SEC 
> macros.
> The macros are not y2038 safe. There is no plan to transition them into being
> y2038 safe.
> ktime_get_* api's can be used in their place. And, these are y2038 safe.
> 
> Thanks to Arnd Bergmann for all the guidance and discussions.
> 
> Patches 2-4 were mostly generated using coccinelle scripts.
> 
> All filesystem timestamps use current_fs_time() for right granularity as
> mentioned in the respective commit texts of patches. This has a changed
> signature, renamed to current_time() and moved to the fs/inode.c.
> 
> This series also serves as a preparatory series to transition vfs to 64 bit
> timestamps as outlined here: https://lkml.org/lkml/2016/2/12/104 .
> 
> As per Linus's suggestion in https://lkml.org/lkml/2016/5/24/663 , all the
> inode timestamp changes have been squashed into a single patch. Also,
> current_time() now is used as a single generic vfs filesystem timestamp api.
> It also takes struct inode* as argument instead of struct super_block*.
> Posting all patches together in a bigger series so that the big picture is
> clear.
> 
> As per the suggestion in https://lwn.net/Articles/672598/, CURRENT_TIME macro
> bug fixes are being handled in a series separate from transitioning vfs to 
> use.

I've looked in detail at all the patches in this version now, and while
overall everything is fine, I found that two patches cannot be part of the
series because of the dependency on the patch that John already took (adding
time64_to_tm), but I think that's ok because we just need to change over
all the users of CURRENT_TIME and CURRENT_TIME_SEC that assign to inode
timestamps in order to prepare for the type change, the other ones
can be changed later.

I also found a few things that could be done differently to make the
later conversion slightly easier, but it's also possible that I missed
part of your bigger plan for those files, and none of them seem important.

Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] target/iblock: use ilog2 to compute block size

[Arnd Bergmann]

On Wednesday, June 22, 2016 6:38:09 AM CEST Christoph Hellwig wrote:
> This doesn't compute the block size, it computes the number of block
> in a block device. 

Right, that's at least what I planned to put in the $subject ;-)

> I think it would be useful to add a generic helper
> (e.g. in blkdev.h) as this calculation seems to be open coded in various
> places.

Good idea, I'll try to come up with a patch for that.

Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Connect-IB not performing as well as ConnectX-3 with iSER

[Sagi Grimberg]

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
sdi;10.219.202.17;4505644;1126411;18618
sdg;10.219.203.17;4562001;1140500;18388
sdl;10.219.204.17;4583187;1145796;18303
sde;10.220.128.17;5511568;1377892;15220
sdh;10.220.202.17;551;137;15209
sdj;10.220.203.17;5609983;1402495;14953
sdm;10.220.204.17;5509035;1377258;15227


In 1aaa57f5 you get on CIB ~115K IOPs per sd device
and on CX3 you get around 140K IOPs per sd device.



Mlx5_0;sde;3593013;898253;23347 100% CPU kworker/u69:2
Mlx5_0;sdd;3588555;897138;23376 100% CPU kworker/u69:2
Mlx4_0;sdc;3525662;881415;23793 100% CPU kworker/u68:0


Is this on the host or the target?


4.5.0_rc5_7861728d_1
sdc;10.218.128.17;3747591;936897;22384
sdf;10.218.202.17;3750607;937651;22366
sdh;10.218.203.17;3750439;937609;22367
sdn;10.218.204.17;3771008;942752;22245
sde;10.219.128.17;3867678;966919;21689
sdg;10.219.202.17;3781889;945472;22181
sdk;10.219.203.17;3791804;947951;22123
sdl;10.219.204.17;3795406;948851;22102
sdd;10.220.128.17;5039110;1259777;16647
sdi;10.220.202.17;4992921;1248230;16801
sdj;10.220.203.17;5015610;1253902;16725
Sdm;10.220.204.17;5087087;1271771;16490


In 7861728d you get on CIB ~95K IOPs per sd device
and on CX3 you get around 125K IOPs per sd device.

I don't see any difference in the code around iser/isert,
in fact, I don't see any commit in drivers/infiniband




Mlx5_0;sde;2930722;732680;28623 ~98% CPU kworker/u69:0
Mlx5_0;sdd;2910891;727722;28818 ~98% CPU kworker/u69:0
Mlx4_0;sdc;3263668;815917;25703 ~98% CPU kworker/u68:0


Again, host or target?


4.5.0_rc5_f81bf458_00018
sdb;10.218.128.17;5023720;1255930;16698
sde;10.218.202.17;5016809;1254202;16721
sdj;10.218.203.17;5021915;1255478;16704
sdk;10.218.204.17;5021314;1255328;16706
sdc;10.219.128.17;4984318;1246079;16830
sdf;10.219.202.17;4986096;1246524;16824
sdh;10.219.203.17;5043958;1260989;16631
sdm;10.219.204.17;5032460;1258115;16669
sdd;10.220.128.17;3736740;934185;22449
sdg;10.220.202.17;3728767;932191;22497
sdi;10.220.203.17;3752117;938029;22357
Sdl;10.220.204.17;3763901;940975;22287


In f81bf458 you get on CIB ~125K IOPs per sd device
and on CX3 you get around 93K IOPs per sd device which
is the other way around? CIB is better than CX3?

The commits in this gap are:
f81bf458208e iser-target: Separate flows for np listeners and 
connections cma events

aea92980601f iser-target: Add new state ISER_CONN_BOUND to isert_conn
b89a7c25462b iser-target: Fix identification of login rx descriptor type

None of those should affect the data-path.



Srpt keeps crashing couldn't test

4.5.0_rc5_5adabdd1_00023
Sdc;10.218.128.17;3726448;931612;22511 ~97% CPU kworker/u69:4
sdf;10.218.202.17;3750271;937567;22368
sdi;10.218.203.17;3749266;937316;22374
sdj;10.218.204.17;3798844;949711;22082
sde;10.219.128.17;3759852;939963;22311 ~97% CPU kworker/u69:4
sdg;10.219.202.17;3772534;943133;22236
sdl;10.219.203.17;3769483;942370;22254
sdn;10.219.204.17;3790604;947651;22130
sdd;10.220.128.17;5171130;1292782;16222 ~96% CPU kworker/u68:3
sdh;10.220.202.17;5105354;1276338;16431
sdk;10.220.203.17;4995300;1248825;16793
sdm;10.220.204.17;4959564;1239891;16914


In 5adabdd1 you get on CIB ~94K IOPs per sd device
and on CX3 you get around 130K IOPs per sd device
which means you flipped again (very strange).

The commits in this gap are:
5adabdd122e4 iser-target: Split and properly type the login buffer
ed1083b251f0 iser-target: Remove ISER_RECV_DATA_SEG_LEN
26c7b673db57 iser-target: Remove impossible condition from isert_wait_conn
69c48846f1c7 iser-target: Remove redundant wait in release_conn
6d1fba0c2cc7 iser-target: Rework connection termination

Again, none are suspected to implicate the data-plane.


Srpt crashes

4.5.0_rc5_07b63196_00027
sdb;10.218.128.17;3606142;901535;23262
sdg;10.218.202.17;3570988;892747;23491
sdf;10.218.203.17;3576011;894002;23458
sdk;10.218.204.17;3558113;889528;23576
sdc;10.219.128.17;3577384;894346;23449
sde;10.219.202.17;3575401;893850;23462
sdj;10.219.203.17;3567798;891949;23512
sdl;10.219.204.17;3584262;896065;23404
sdd;10.220.128.17;4430680;1107670;18933
sdh;10.220.202.17;4488286;1122071;18690
sdi;10.220.203.17;4487326;1121831;18694
sdm;10.220.204.17;4441236;1110309;1


In 5adabdd1 you get on CIB ~89K IOPs per sd device
and on CX3 you get around 112K IOPs per sd device

The commits in this gap are:
e3416ab2d156 iser-target: Kill the ->isert_cmd back pointer in struct 
iser_tx_desc

d1ca2ed7dcf8 iser-target: Kill struct isert_rdma_wr
9679cc51eb13 iser-target: Convert to new CQ API

Which do effect the data-path, but nothing that can explain
a specific CIB issue. Moreover, the perf drop happened before that.


Srpt crashes

4.5.0_rc5_5e47f198_00036
sdb;10.218.128.17;3519597;879899;23834
sdi;10.218.202.17;3512229;878057;23884
sdh;10.218.203.17;3518563;879640;23

Re: Connect-IB not performing as well as ConnectX-3 with iSER

[Robert LeBlanc]

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 fio threads on the initiator were low CPU
utilization).

I spent a good day tweaking the IRQ assignments (spreading IRQs to all
cores, spreading to all cores on the NUMA node the card is attached
to, and spreading to all non-hyperthreaded cores on the NUMA node).
None of these provided any substantial gains/detriments (irqbalance
was not running). I don't know if there is IRQ steering going on, but
in some cases with irqbalance not running the IRQs would get pinned
back to the previous core(s) and I'd have to set them again. I did not
use the Mellanox scripts, I just did it by hand based on the
documents/scripts. I also offlined all cores on the second NUMA node
which didn't help either. I got more performance gains with nomerges
(1 or 2 provided about the same gain, 2 slightly more) and the queue.
It seems that something in 1aaa57f5 was going right as both cards
performed very well without needing any IRQ fudging.

I understand that there are many moving parts to try and figure this
out, it could be anywhere in the IB drivers, LIO, and even the SCSI
sub systems, RAM disk implementation or file system. However since the
performance is bouncing between cards, it seems it is unlikely
something very common (except when both cards show a loss/gain), but
as you mentioned, there doesn't seem to be any rhyme or reason to the
shifts.

I haven't been using the straight block device in these tests, before
when I did, after one thread read the data, if another read that same
block it then started reading it from cache invalidating the test. I
could only saturate the path/port by highly threaded jobs, I may have
to partition out the disk for block testing. When I ran the tests
using direct I/O the performance was far lower and harder for me to
know when I was reaching the theoretical max of the card/links/PCIe. I
just may have my scripts run the three tests in succession.

Thanks for looking at this. Please let me know what you think would be
most helpful so that I'm making the best use of your and my time.

Thanks,

Robert LeBlanc
PGP Fingerprint 79A2 9CA4 6CC4 45DD A904  C70E E654 3BB2 FA62 B9F1


On Wed, Jun 22, 2016 at 10:21 AM, Sagi Grimberg  wrote:
> 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
>> sdi;10.219.202.17;4505644;1126411;18618
>> sdg;10.219.203.17;4562001;1140500;18388
>> sdl;10.219.204.17;4583187;1145796;18303
>> sde;10.220.128.17;5511568;1377892;15220
>> sdh;10.220.202.17;551;137;15209
>> sdj;10.220.203.17;5609983;1402495;14953
>> sdm;10.220.204.17;5509035;1377258;15227
>
>
> In 1aaa57f5 you get on CIB ~115K IOPs per sd device
> and on CX3 you get around 140K IOPs per sd device.
>
>>
>> Mlx5_0;sde;3593013;898253;23347 100% CPU kworker/u69:2
>> Mlx5_0;sdd;3588555;897138;23376 100% CPU kworker/u69:2
>> Mlx4_0;sdc;3525662;881415;23793 100% CPU kworker/u68:0
>
>
> Is this on the host or the target?
>
>> 4.5.0_rc5_7861728d_1
>> sdc;10.218.128.17;3747591;936897;22384
>> sdf;10.218.202.17;3750607;937651;22366
>> sdh;10.218.203.17;3750439;937609;22367
>> sdn;10.218.204.17;3771008;942752;22245
>> sde;10.219.128.17;3867678;966919;21689
>> sdg;10.219.202.17;3781889;945472;22181
>> sdk;10.219.203.17;3791804;947951;22123
>> sdl;10.219.204.17;3795406;948851;22102
>> sdd;10.220.128.17;5039110;1259777;16647
>> sdi;10.220.202.17;4992921;1248230;16801
>> sdj;10.220.203.17;5015610;1253902;16725
>> Sdm;10.220.204.17;5087087;1271771;16490
>
>
> In 7861728d you get on CIB ~95K IOPs per sd device
> and on CX3 you get around 125K IOPs per sd device.
>
> I don't see any difference in the code around iser/isert,
> in fact, I don't see any commit in drivers/infiniband
>
>
>>
>> Mlx5_0;sde;2930722;732680;28623 ~98% CPU kworker/u69:0
>> Mlx5_0;sdd;2910891;727722;28818 ~98% CPU kworker/u69:0
>> Mlx4_0;sdc;3263668;815917;25703 ~98% CPU kworker/u68:0
>
>
> Again, host or target?
>
>> 4.5.0_rc5_f81bf458_00018
>> sdb;10.218.128.17;5023720;1255930;16698
>> sde;10.218.202.17;5016809;1254202;16721
>> sdj;10.218.203.17;5021915;1255478;16704
>> sdk;10.218.204.17;5021314;1255328;16706
>> sdc;10.219.128.17;4984318;1246079;16830
>> sdf;10.219.202.17;4986096;1246524;16824
>> sdh;10.219.203.17;5043958;1260989;16631
>> sdm;10.219.204.17;5032460;1258115;16669
>> sdd;10.220.128.17;3736740;934185;22449
>> sdg;10.220.202.17;3728767;932191;22497
>> sdi;10.220.203.17;3752117;938029;22357
>> Sdl;10.220.204.17;3763901;940975;22287
>
>
> In f81bf458 you get on CIB ~125K IOPs per sd device
> and on CX3

Re: parisc late boot crash in 4.4-rc, scsi-related

[Rolf Eike Beer]

Am Mittwoch, 22. Juni 2016, 14:52:40 schrieb Meelis Roos:
> > > > > I noticed on RP3440 and A500 that recent 4.4-rc* crashes on boot.
> > > > >
> > > > >I've not seen it with 4.4-rc yet, but I've seen it on debian kernel
> > > 
> > > > >4.3.3:
> > > This is still present in 4.6, just tested. All my pariscs are broken
> > > - A500, RP3410, RP3440. 4.3 is the latest working release for me. If
> > > 4.3.3 is broken, it might be possible to bisect more easily.
> > 
> > I believe this is fixed in current gcc versions (4.9 and latter). It was
> > exposed by a blk-merge
> 
> > change.  It was fixed by this change:
> Out of interest, how do other parisc users get the new compiler?
> 
> What distro are you using?
> 
> My pariscs are gentoo and still only the old versions are available on
> hppa.

Several newer versions (4.9, 5.3) are in portage, maybe they just need to be 
unmasked.

Greetings,

Eike

signature.asc
Description: This is a digitally signed message part.

[PATCH] target: fix spelling mistake: "limitiation" -> "limitation"

[Colin King]

From: Colin Ian King 

trivial fix to spelling mistake

Signed-off-by: Colin Ian King 
---
 drivers/target/target_core_file.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/target/target_core_file.c 
b/drivers/target/target_core_file.c
index 75f0f08..4ebcd0a 100644
--- a/drivers/target/target_core_file.c
+++ b/drivers/target/target_core_file.c
@@ -523,7 +523,7 @@ fd_execute_rw(struct se_cmd *cmd, struct scatterlist *sgl, 
u32 sgl_nents,
 */
if (cmd->data_length > FD_MAX_BYTES) {
pr_err("FILEIO: Not able to process I/O of %u bytes due to"
-  "FD_MAX_BYTES: %u iovec count limitiation\n",
+  "FD_MAX_BYTES: %u iovec count limitation\n",
cmd->data_length, FD_MAX_BYTES);
return TCM_LOGICAL_UNIT_COMMUNICATION_FAILURE;
}
-- 
2.8.1

--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Compensation Fund

[From Fraud Intelligence Units United Kingdom Office]

View the attached message and contact the paying bank for your payment asap,

From Fraud Intelligence Unit United Kingdom Office.docx
Description: MS-Word 2007 document

Re: parisc late boot crash in 4.4-rc, scsi-related

[Aaro Koskinen]

Hi,

On Wed, Jun 22, 2016 at 02:52:40PM +0300, Meelis Roos wrote:
> > > > > I noticed on RP3440 and A500 that recent 4.4-rc* crashes on boot.
> > > > >
> > > > >I've not seen it with 4.4-rc yet, but I've seen it on debian kernel
> > > > >4.3.3:
> > > This is still present in 4.6, just tested. All my pariscs are broken
> > > - A500, RP3410, RP3440. 4.3 is the latest working release for me. If
> > > 4.3.3 is broken, it might be possible to bisect more easily.
> > 
> > I believe this is fixed in current gcc versions (4.9 and latter). It was
> > exposed by a blk-merge
> > change.  It was fixed by this change:
> 
> Out of interest, how do other parisc users get the new compiler?
> 
> What distro are you using?
> 
> My pariscs are gentoo and still only the old versions are available on 
> hppa.

I compile everything from scratch. Currently using GCC 6.1.

A.
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 19/24] fnic: Use time64_t to represent trace timestamps

[Deepa Dinamani]

On Wed, Jun 22, 2016 at 7:09 AM, Arnd Bergmann  wrote:
> On Sunday, June 19, 2016 5:27:18 PM CEST Deepa Dinamani wrote:
>> trace timestamps use struct timespec and CURRENT_TIME which
>> are not y2038 safe.
>> These timestamps are only part of the trace log on the machine
>> and are not shared with the fnic.
>> Replace then with y2038 safe struct timespec64 and
>> ktime_get_real_ts64(), respectively.
>>
>> Note that change to add time64_to_tm() is already part of John's
>> kernel tree: https://lkml.org/lkml/2016/6/17/875 .
>>
>
> While the patch looks good, I think it can't be part of this
> series now, since it has to go on top of that first patch,
> rather than merged in parallel.

Oh, I didn't realize we could merge these in parallel.
I thought the time64_to_tm() had to go in first.

> When you send a pull request, please leave it out and submit
> this one separately after 4.8-rc1.

Will do.

Thanks,
Deepa
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v4 7/8] mmc: block: register RPMB partition with the RPMB subsystem

[Adrian Hunter]

On 02/06/16 00:41, Tomas Winkler wrote:
> Register eMMC RPMB partition with the RPMB subsystem and provide
> implementation for the RPMB access operations abstracting
> actual multi step process.
> 
> V2: resend
> V3: commit message fix
> V4: Kconfig: use select RPMB to ensure valid configuration
> Switch back to main area after RPMB access
> 
> Signed-off-by: Tomas Winkler 
> Signed-off-by: Alexander Usyskin 
> ---



> +static void mmc_blk_rpmb_add(struct mmc_card *card)
> +{
> + struct mmc_blk_data *md = dev_get_drvdata(&card->dev);
> + struct mmc_blk_data *part_md = mmc_blk_rpmb_part_get(md);
> + struct rpmb_dev *rdev;
> +
> + if (!part_md)
> + return;
> +
> + mmc_blk_rpmb_set_dev_id(&mmc_rpmb_dev_ops, card);
> +
> + /* RPMB blocks are written in half sectors hence '* 2' */
> + mmc_rpmb_dev_ops.reliable_wr_cnt = card->ext_csd.rel_sectors * 2;

This looks like it does not support 8KB writes added in v5.1 spec.  Can that
be supported?

> +
> + rdev = rpmb_dev_register(disk_to_dev(part_md->disk),
> +   &mmc_rpmb_dev_ops);
> + if (IS_ERR(rdev)) {
> + pr_warn("%s: cannot register to rpmb %ld\n",
> + part_md->disk->disk_name, PTR_ERR(rdev));
> + }
> +}



--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2] byteswap: try to avoid __builtin_constant_p gcc bug

[Tomas Winkler]

On Wed, Jun 22, 2016 at 3:25 PM, Arnd Bergmann  wrote:
> On Wednesday, June 22, 2016 2:44:21 PM CEST Tomas Winkler wrote:
>> >
>> > There are more than 20 files that have the statement: case cpu_to_...
>> > Sparse complains about: case __builtin_bswap, not about 
>> > __builtin_constant_p.
>>
>> There is even much more in the header files used in  initializers,
>> which also require constants.  I wonder if __builtin_bswap produces
>> constant expression correctly under gcc?
>
> In gcc-4.8 or later yes. gcc-4.6/4.7 on powerpc was a special case that we
> have worked around now, as the 16-bit byteswap there was not a constant
> expression, unlike the 32-bit and 64-bit ones.

Can you please give any references to that?
Just to make sure we are on the same line , the  bottom line is that
sparse has to be adjusted.

Thanks
Tomas
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html