[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Xen-changelog] [linux-2.6.18-xen] blkback: Fit the important information of the thread in 17 characters


  • To: xen-changelog@xxxxxxxxxxxxxxxxxxx
  • From: Xen patchbot-linux-2.6.18-xen <patchbot@xxxxxxx>
  • Date: Wed, 25 May 2016 14:11:02 +0000
  • Delivery-date: Wed, 25 May 2016 14:11:09 +0000
  • List-id: "Change log for Mercurial \(receive only\)" <xen-changelog.lists.xen.org>

# HG changeset patch
# User Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>
# Date 1464184860 -7200
#      Wed May 25 16:01:00 2016 +0200
# Node ID d98fd9aa81eaf7b0108fc1b2bd1d7bbd248b0e81
# Parent  d018557a9a503dcccad5d1a56b3dc3dfc072c73f
blkback: Fit the important information of the thread in 17 characters

The processes names are truncated to 17, while we had the length
of the process as name 20 - which meant that while we filled
it out with various details - the last 3 characters (which had
the queue number) never surfaced to the user-space.

To simplify this and be able to fit the device name, domain id,
and the queue number we remove the 'blkback' from the name.

Prior to this patch the device name is "blkback.<domid>.<name>"
for example: blkback.8.xvda, blkback.11.hda.

With the multiqueue block backend we add "-%d" for the queue.
But sadly this is already way past the limit so it gets stripped.

Possible solution had been identified by Ian:
http://lists.xenproject.org/archives/html/xen-devel/2015-05/msg03516.html

  "
  If you are pressed for space then the "xvd" is probably a bit redundant
  in a string which starts blkbk.

  The guest may not even call the device xvdN (iirc BSD has another
  prefix) any how, so having blkback say so seems of limited use anyway.

  Since this seems to not include a partition number how does this work in
  the split partition scheme? (i.e. one where the guest is given xvda1 and
  xvda2 rather than xvda with a partition table)

[It will be 'blkback.8.xvda1', and 'blkback.11.xvda2']

  Perhaps something derived from one of the schemes in
  http://xenbits.xen.org/docs/unstable/misc/vbd-interface.txt might be a
  better fit?

After a bit of discussion (see
http://lists.xenproject.org/archives/html/xen-devel/2015-12/msg01588.html)
we settled on dropping the "blkback" part.

This will make it possible to have the <domid>.<name>-<queue>:

 [1.xvda-0]
 [1.xvda-1]

And we enough space to make it go up to:

 [32100.xvdfg9-5]

Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>

Extend to blktap, altering the use of '.' as separator to make thread
names distinguishable.

Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
Committed-by: Jan Beulich <jbeulich@xxxxxxxx>
---


diff -r d018557a9a50 -r d98fd9aa81ea drivers/xen/blkback/xenbus.c
--- a/drivers/xen/blkback/xenbus.c      Mon Feb 22 15:25:36 2016 +0100
+++ b/drivers/xen/blkback/xenbus.c      Wed May 25 16:01:00 2016 +0200
@@ -78,7 +78,7 @@ static void update_blkif_status(blkif_t 
        }
 
        blkif->xenblkd = kthread_run(blkif_schedule, blkif,
-                                    "blkbk.%d.%s", blkif->domid, devname);
+                                    "%d.%s", blkif->domid, devname);
        kfree(devname);
        if (IS_ERR(blkif->xenblkd)) {
                err = PTR_ERR(blkif->xenblkd);
diff -r d018557a9a50 -r d98fd9aa81ea drivers/xen/blktap/xenbus.c
--- a/drivers/xen/blktap/xenbus.c       Mon Feb 22 15:25:36 2016 +0100
+++ b/drivers/xen/blktap/xenbus.c       Wed May 25 16:01:00 2016 +0200
@@ -231,7 +231,7 @@ static void tap_update_blkif_status(blki
        }
 
        blkif->xenblkd = kthread_run(tap_blkif_schedule, blkif,
-                                    "blktap.%d.%s", blkif->domid, devname);
+                                    "%d:%s", blkif->domid, devname);
        if (IS_ERR(blkif->xenblkd)) {
                err = PTR_ERR(blkif->xenblkd);
                blkif->xenblkd = NULL;

_______________________________________________
Xen-changelog mailing list
Xen-changelog@xxxxxxxxxxxxx
http://lists.xensource.com/xen-changelog

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.