Eaarn More Weekly $$

[Chevron Oil]

Drive round the city with our logo placed on your vehicle for $400 income wkly. 
Reply 4 details.

Alexander Cummings
Hiring Manager




This email and any attachments are confidential and intended solely for the use 
of the individual(s) to whom it is addressed. If you are not the intended 
recipient, be advised that you have received this email in error and any use, 
dissemination, forwarding, printing or copying of it is strictly prohibited - 
please delete it from your system and notify the sender.
 
Any views or opinions presented are solely those of the author and do not 
necessarily represent those of Republic Technologies. If the content of this 
email and any attachments are to become contractually binding it must be made 
in writing and signed by a duly authorised representative of Republic 
Technologies.
 
Although we have taken steps to ensure the email and its attachments are 
virus-free, we cannot guarantee this or accept any responsibility, and it is 
the responsibility of recipients to carry out their own virus checks.

Republic Technologies (UK) Limited
Registered in England and Wales with company number: 873671
Registered Office: Sword House, Totteridge Road, High Wycombe, Buckinghamshire, 
HP13 6DG

__
This email has been scanned by the Symantec Email Security.cloud service.
For more information please visit http://www.symanteccloud.com
__

Re: Increased memory usage with scsi-mq

[Richard W.M. Jones]

On Sat, Aug 05, 2017 at 03:39:54PM +0200, Christoph Hellwig wrote:
> For now can you apply this testing patch to the guest kernel?
> 
> diff --git a/drivers/scsi/virtio_scsi.c b/drivers/scsi/virtio_scsi.c
> index 9be211d68b15..0cbe2c882e1c 100644
> --- a/drivers/scsi/virtio_scsi.c
> +++ b/drivers/scsi/virtio_scsi.c
> @@ -818,7 +818,7 @@ static struct scsi_host_template 
> virtscsi_host_template_single = {
>   .eh_timed_out = virtscsi_eh_timed_out,
>   .slave_alloc = virtscsi_device_alloc,
>  
> - .can_queue = 1024,
> + .can_queue = 64,
>   .dma_boundary = UINT_MAX,
>   .use_clustering = ENABLE_CLUSTERING,
>   .target_alloc = virtscsi_target_alloc,
> @@ -839,7 +839,7 @@ static struct scsi_host_template 
> virtscsi_host_template_multi = {
>   .eh_timed_out = virtscsi_eh_timed_out,
>   .slave_alloc = virtscsi_device_alloc,
>  
> - .can_queue = 1024,
> + .can_queue = 64,
>   .dma_boundary = UINT_MAX,
>   .use_clustering = ENABLE_CLUSTERING,
>   .target_alloc = virtscsi_target_alloc,
> @@ -983,7 +983,7 @@ static int virtscsi_probe(struct virtio_device *vdev)
>   shost->max_id = num_targets;
>   shost->max_channel = 0;
>   shost->max_cmd_len = VIRTIO_SCSI_CDB_SIZE;
> - shost->nr_hw_queues = num_queues;
> + shost->nr_hw_queues = 1;
>  
>  #ifdef CONFIG_BLK_DEV_INTEGRITY
>   if (virtio_has_feature(vdev, VIRTIO_SCSI_F_T10_PI)) {

Yes, that's an improvement, although it's still a little way off the
density possible the old way:

  With scsi-mq enabled:   175 disks
* With this patch:319 disks *
  With scsi-mq disabled: 1755 disks

Also only the first two hunks are necessary.  The kernel behaves
exactly the same way with or without the third hunk (ie. num_queues
must already be 1).

Can I infer from this that qemu needs a way to specify the can_queue
setting to the virtio-scsi driver in the guest kernel?

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
libguestfs lets you edit virtual machines.  Supports shell scripting,
bindings from many languages.  http://libguestfs.org

Re: [PATCH v2 00/13] mpt3sas driver NVMe support:

[James Bottomley]

On Sat, 2017-08-05 at 06:53 -0700, Christoph Hellwig wrote:
> On Wed, Aug 02, 2017 at 10:14:40AM +0200, Hannes Reinecke wrote:
> > 
> > I'm not happy with this approach.
> > NVMe devices should _not_ appear as SCSI devices; this will just
> > confuse matters _and_ will be incompatible with 'normal' NVMe
> > devices.
> > 
> > Rather I would like to see the driver to hook into the existing
> > NVMe framework (which essentially means to treat the mpt3sas as a
> > weird NVMe-over-Fabrics HBA), and expose the NVMe devices like any
> > other NVMe HBA.
> 
> That doesn't make any sense.  The devices behind the mpt adapter
> don't look like NVMe devices at all for the hosts - there are no NVMe
> commands or queues involved at all, they hide behind the same
> somewhat leaky scsi abstraction as other devices behind the mpt
> controller.

You might think about what we did for SAS: split the generic handler
into two pieces, libsas for driving the devices, which mpt didn't need
because of the fat firmware and the SAS transport class so mpt could at
least show the same sysfs files as everything else for SAS devices.

Fortunately for NVMe it's very simple at the moment its just a couple
of host files and wwid on the devices.

James


> The only additional leak is that the controller now supports NVMe-
> like PRPs in additions to its existing two SGL formats.
> 

[PATCH] scsi: libcxgbi: use ndev->ifindex to find route

[Varun Prakash]

If cxgbi_ep_connect() is called with valid shost
then find associated ndev and use ndev->ifindex
to find route.

Signed-off-by: Varun Prakash 
---
 drivers/scsi/cxgbi/libcxgbi.c | 27 ++-
 1 file changed, 18 insertions(+), 9 deletions(-)

diff --git a/drivers/scsi/cxgbi/libcxgbi.c b/drivers/scsi/cxgbi/libcxgbi.c
index 1a4cfa5..512c8f1 100644
--- a/drivers/scsi/cxgbi/libcxgbi.c
+++ b/drivers/scsi/cxgbi/libcxgbi.c
@@ -585,19 +585,21 @@ static struct cxgbi_sock *cxgbi_sock_create(struct 
cxgbi_device *cdev)
 
 static struct rtable *find_route_ipv4(struct flowi4 *fl4,
  __be32 saddr, __be32 daddr,
- __be16 sport, __be16 dport, u8 tos)
+ __be16 sport, __be16 dport, u8 tos,
+ int ifindex)
 {
struct rtable *rt;
 
rt = ip_route_output_ports(_net, fl4, NULL, daddr, saddr,
-  dport, sport, IPPROTO_TCP, tos, 0);
+  dport, sport, IPPROTO_TCP, tos, ifindex);
if (IS_ERR(rt))
return NULL;
 
return rt;
 }
 
-static struct cxgbi_sock *cxgbi_check_route(struct sockaddr *dst_addr)
+static struct cxgbi_sock *
+cxgbi_check_route(struct sockaddr *dst_addr, int ifindex)
 {
struct sockaddr_in *daddr = (struct sockaddr_in *)dst_addr;
struct dst_entry *dst;
@@ -611,7 +613,8 @@ static struct cxgbi_sock *cxgbi_check_route(struct sockaddr 
*dst_addr)
int port = 0x;
int err = 0;
 
-   rt = find_route_ipv4(, 0, daddr->sin_addr.s_addr, 0, 
daddr->sin_port, 0);
+   rt = find_route_ipv4(, 0, daddr->sin_addr.s_addr, 0,
+daddr->sin_port, 0, ifindex);
if (!rt) {
pr_info("no route to ipv4 0x%x, port %u.\n",
be32_to_cpu(daddr->sin_addr.s_addr),
@@ -693,11 +696,13 @@ static struct cxgbi_sock *cxgbi_check_route(struct 
sockaddr *dst_addr)
 
 #if IS_ENABLED(CONFIG_IPV6)
 static struct rt6_info *find_route_ipv6(const struct in6_addr *saddr,
-   const struct in6_addr *daddr)
+   const struct in6_addr *daddr,
+   int ifindex)
 {
struct flowi6 fl;
 
memset(, 0, sizeof(fl));
+   fl.flowi6_oif = ifindex;
if (saddr)
memcpy(, saddr, sizeof(struct in6_addr));
if (daddr)
@@ -705,7 +710,8 @@ static struct rt6_info *find_route_ipv6(const struct 
in6_addr *saddr,
return (struct rt6_info *)ip6_route_output(_net, NULL, );
 }
 
-static struct cxgbi_sock *cxgbi_check_route6(struct sockaddr *dst_addr)
+static struct cxgbi_sock *
+cxgbi_check_route6(struct sockaddr *dst_addr, int ifindex)
 {
struct sockaddr_in6 *daddr6 = (struct sockaddr_in6 *)dst_addr;
struct dst_entry *dst;
@@ -719,7 +725,7 @@ static struct cxgbi_sock *cxgbi_check_route6(struct 
sockaddr *dst_addr)
int port = 0x;
int err = 0;
 
-   rt = find_route_ipv6(NULL, >sin6_addr);
+   rt = find_route_ipv6(NULL, >sin6_addr, ifindex);
 
if (!rt) {
pr_info("no route to ipv6 %pI6 port %u\n",
@@ -2536,6 +2542,7 @@ struct iscsi_endpoint *cxgbi_ep_connect(struct Scsi_Host 
*shost,
struct cxgbi_endpoint *cep;
struct cxgbi_hba *hba = NULL;
struct cxgbi_sock *csk;
+   int ifindex = 0;
int err = -EINVAL;
 
log_debug(1 << CXGBI_DBG_ISCSI | 1 << CXGBI_DBG_SOCK,
@@ -2548,13 +2555,15 @@ struct iscsi_endpoint *cxgbi_ep_connect(struct 
Scsi_Host *shost,
pr_info("shost 0x%p, priv NULL.\n", shost);
goto err_out;
}
+
+   ifindex = hba->ndev->ifindex;
}
 
if (dst_addr->sa_family == AF_INET) {
-   csk = cxgbi_check_route(dst_addr);
+   csk = cxgbi_check_route(dst_addr, ifindex);
 #if IS_ENABLED(CONFIG_IPV6)
} else if (dst_addr->sa_family == AF_INET6) {
-   csk = cxgbi_check_route6(dst_addr);
+   csk = cxgbi_check_route6(dst_addr, ifindex);
 #endif
} else {
pr_info("address family 0x%x NOT supported.\n",
-- 
2.0.2

Re: [PATCH v2 00/13] mpt3sas driver NVMe support:

[Christoph Hellwig]

On Wed, Aug 02, 2017 at 10:14:40AM +0200, Hannes Reinecke wrote:
> I'm not happy with this approach.
> NVMe devices should _not_ appear as SCSI devices; this will just confuse
> matters _and_ will be incompatible with 'normal' NVMe devices.
> 
> Rather I would like to see the driver to hook into the existing NVMe
> framework (which essentially means to treat the mpt3sas as a weird
> NVMe-over-Fabrics HBA), and expose the NVMe devices like any other NVMe HBA.

That doesn't make any sense.  The devices behind the mpt adapter don't
look like NVMe devices at all for the hosts - there are no NVMe commands
or queues involved at all, they hide behind the same somewhat leaky
scsi abstraction as other devices behind the mpt controller.

The only additional leak is that the controller now supports NVMe-like
PRPs in additions to its existing two SGL formats.

Re: [PATCH 04/14] blk-mq-sched: improve dispatching from sw queue

[Ming Lei]

On Thu, Aug 03, 2017 at 05:33:13PM +, Bart Van Assche wrote:
> On Thu, 2017-08-03 at 11:13 +0800, Ming Lei wrote:
> > On Thu, Aug 03, 2017 at 01:35:29AM +, Bart Van Assche wrote:
> > > On Wed, 2017-08-02 at 11:31 +0800, Ming Lei wrote:
> > > > On Tue, Aug 01, 2017 at 03:11:42PM +, Bart Van Assche wrote:
> > > > > On Tue, 2017-08-01 at 18:50 +0800, Ming Lei wrote:
> > > > > > On Tue, Aug 01, 2017 at 06:17:18PM +0800, Ming Lei wrote:
> > > > > > > How can we get the accurate 'number of requests in progress' 
> > > > > > > efficiently?
> > > > > 
> > > > > Hello Ming,
> > > > > 
> > > > > How about counting the number of bits that have been set in the tag 
> > > > > set?
> > > > > I am aware that these bits can be set and/or cleared concurrently 
> > > > > with the
> > > > > dispatch code but that count is probably a good starting point.
> > > > 
> > > > It has to be atomic_t, which is too too heavy for us, please see the 
> > > > report:
> > > > 
> > > > http://marc.info/?t=14986844843=1=2
> > > > 
> > > > Both Jens and I want to kill hd_struct.in_flight, but looks still no
> > > > good way. 
> > > 
> > > Hello Ming,
> > > 
> > > Sorry but I disagree that a new atomic variable should be added to keep 
> > > track
> > > of the number of busy requests. Counting the number of bits that are set 
> > > in
> > > the tag set should be good enough in this context.
> > 
> > That won't work because the tag set is host wide and shared by all LUNs.
> 
> Hello Ming,
> 
> Are you aware that the SCSI core already keeps track of the number of busy 
> requests
> per LUN? See also the device_busy member of struct scsi_device. How about 
> giving the
> block layer core access in some way to that counter?

Yes, I know that.

Last time I mentioned it to Christoph that this counter can be used for
implementing Runtime PM for avoiding to introduce one new counter to 
account pending I/O.

But for this purpose(estimating how many requests to dequeue from hctxs),
it isn't a good idea:

1) strictly speaking, atomic counter isn't enough, and lock 
is needed, because we need to make sure that the counter can't
be changed during dequeuing requests, so exporting the counter
to block won't work

2) even though you may think it is just for estimating, and
not use a lock, it isn't good too, because for some SCSI devices,
q->queue_depth is very small, both qla2xxx and lfpc's .cmd_perf_lun
is 3. So it can be very inaccurate since it is normal to dequeue
requests from all hctx at the same time.

Also I have posted V2 today, from the test result on SRP, looks
it is good to dequeue one request one time, so I suggest that we
follow mq scheduler's way to dequeue request(pick up one in one time)
for blk-mq 'none' in this patchset. We may consider to improve
it in future if there is better & mature idea.


Thanks,
Ming

Re: Increased memory usage with scsi-mq

[Christoph Hellwig]

For now can you apply this testing patch to the guest kernel?

diff --git a/drivers/scsi/virtio_scsi.c b/drivers/scsi/virtio_scsi.c
index 9be211d68b15..0cbe2c882e1c 100644
--- a/drivers/scsi/virtio_scsi.c
+++ b/drivers/scsi/virtio_scsi.c
@@ -818,7 +818,7 @@ static struct scsi_host_template 
virtscsi_host_template_single = {
.eh_timed_out = virtscsi_eh_timed_out,
.slave_alloc = virtscsi_device_alloc,
 
-   .can_queue = 1024,
+   .can_queue = 64,
.dma_boundary = UINT_MAX,
.use_clustering = ENABLE_CLUSTERING,
.target_alloc = virtscsi_target_alloc,
@@ -839,7 +839,7 @@ static struct scsi_host_template 
virtscsi_host_template_multi = {
.eh_timed_out = virtscsi_eh_timed_out,
.slave_alloc = virtscsi_device_alloc,
 
-   .can_queue = 1024,
+   .can_queue = 64,
.dma_boundary = UINT_MAX,
.use_clustering = ENABLE_CLUSTERING,
.target_alloc = virtscsi_target_alloc,
@@ -983,7 +983,7 @@ static int virtscsi_probe(struct virtio_device *vdev)
shost->max_id = num_targets;
shost->max_channel = 0;
shost->max_cmd_len = VIRTIO_SCSI_CDB_SIZE;
-   shost->nr_hw_queues = num_queues;
+   shost->nr_hw_queues = 1;
 
 #ifdef CONFIG_BLK_DEV_INTEGRITY
if (virtio_has_feature(vdev, VIRTIO_SCSI_F_T10_PI)) {

Re: [PATCH 3/4] scsi: add Mylex RAID controller

[Christoph Hellwig]

Can you use normal linux style for the code instead of copy and
pasting the weird naming and capitalization from the DAC960 driver?

Also please use the driver name as prefix for the functions.

Maybe myraid instead of mylex?

I'll take a more detailed look at the actual driver in a bit.

Re: [PATCH] scsi: sg: Prevent potential double frees in sg driver

[Christoph Hellwig]

This looks correct and safe to me, but I wonder if anyone relies
on multi-threaded /dev/sg write usage, which would be completely
serialized with this.

Re: [PATCH] scsi-mq: Always unprepare before requeuing a request

[Christoph Hellwig]

Looks fine,

Reviewed-by: Christoph Hellwig 

Re: [PATCH] scsi_dh_alua: suppress errors from unsupported devices

[Christoph Hellwig]

>   error = scsi_dh_add_device(sdev);
> - if (error)
> - /*
> -  * device_handler is optional, so any error can be ignored
> -  */
> - sdev_printk(KERN_INFO, sdev,
> - "failed to add device handler: %d\n", error);
> + /* device_handler is optional, so any error can be ignored */

In that case it should return void.

Re: [PATCH 2/2] sd_zbc: Write unlock zones from sd_uninit_cmnd()

[Christoph Hellwig]

Looks fine,

Reviewed-by: Christoph Hellwig 

Re: [PATCH 1/2] block: Zoned block device single-threaded submission

[Christoph Hellwig]

We'll need a blk-mq version as well, otherwise: NAK.

Re: [Regression 4.13-rc1] Resume does not work on Lenovo X60t

[Christoph Hellwig]

On Thu, Aug 03, 2017 at 07:42:15PM +0200, Paul Menzel wrote:
> Dear Linux folks,
> 
> 
> Since the merge windows opened for Linux 4.13, I am unable to resume from
> ACPI S3 suspend on a Lenovo X60t. The graphics comes back, but I am unable
> to enter anything, and the system seems to be hung. Magic SysRq keys still
> work though, but powering the system of doesn’t work. The power button also
> does not work.
> 
> Please find the stack trace with Linux 4.13-rc3 captured over the serial
> console below.

Is this really -rc3?  rc3 has a commit to disable block runtime pm
for blk-mq, which is now the default for scsi.  So with -rc1 we've
seen similar reports, but rc3 would be odd and suggest we have further
problems.

Re: Increased memory usage with scsi-mq

[Richard W.M. Jones]

On Sat, Aug 05, 2017 at 10:44:36AM +0200, Christoph Hellwig wrote:
> On Fri, Aug 04, 2017 at 10:00:47PM +0100, Richard W.M. Jones wrote:
> > I read your slides about scsi-mq and it seems like a significant
> > benefit to large machines, but could the out of the box defaults be
> > made more friendly for small memory machines?
> 
> The default inumber of queues and queue depth and thus memory usage is
> set by the LLDD.
> 
> Try to reduce the can_queue value in virtio_scsi and/or make sure
> you use the single queue variant in your VM (which should be tunable
> in qemu).

Thanks, this is interesting.

Virtio-scsi seems to have a few settable parameters that might be
related to this:

  DEFINE_PROP_UINT32("num_queues", VirtIOSCSI, parent_obj.conf.num_queues, 1),
  DEFINE_PROP_UINT32("max_sectors", VirtIOSCSI, parent_obj.conf.max_sectors,
0x),
  DEFINE_PROP_UINT32("cmd_per_lun", VirtIOSCSI, parent_obj.conf.cmd_per_lun,
128),

Unfortunately (assuming I'm setting them right - see below), none of
them have any effect on the number of disks that I can add to the VM.

I am testing them by placing them in the ‘-device virtio-scsi-pci’
parameter, ie. as a property of the controller, not a property of the
LUN, eg:

-device virtio-scsi-pci,cmd_per_lun=32,id=scsi \
-drive 
file=/home/rjones/d/libguestfs/tmp/libguestfshXImTv/scratch.1,cache=unsafe,format=raw,id=hd0,if=none
 \
-device scsi-hd,drive=hd0 \

The debugging output is a bit too large to attach to this email, but I
have placed it at the link below.  It contains (if you scroll down a
bit) the full qemu command line and full kernel output.

  http://oirase.annexia.org/tmp/bz1478201-log.txt

I can add some extra debugging into the kernel if you like.  Just
point me to the right place.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-builder quickly builds VMs from scratch
http://libguestfs.org/virt-builder.1.html

Re: Increased memory usage with scsi-mq

[Christoph Hellwig]

On Fri, Aug 04, 2017 at 10:00:47PM +0100, Richard W.M. Jones wrote:
> I read your slides about scsi-mq and it seems like a significant
> benefit to large machines, but could the out of the box defaults be
> made more friendly for small memory machines?

The default inumber of queues and queue depth and thus memory usage is
set by the LLDD.

Try to reduce the can_queue value in virtio_scsi and/or make sure
you use the single queue variant in your VM (which should be tunable
in qemu).

Re: [PATCH 04/14] blk-mq-sched: improve dispatching from sw queue

[h...@infradead.org]

On Thu, Aug 03, 2017 at 05:33:13PM +, Bart Van Assche wrote:
> Are you aware that the SCSI core already keeps track of the number of busy 
> requests
> per LUN? See also the device_busy member of struct scsi_device. How about 
> giving the
> block layer core access in some way to that counter?

I'd love ot move it to blk-mq in a scalable way eventually, as
we'll run into the same problems with NVMe systems with multiple
namespaces.