[PATCH v2 0/6] Drivers: hv: vmbus: fair round robin algorithm for vmbus_get_outgoing_channel()

[Vitaly Kuznetsov]

Changes in v2:
- Address Dexuan's review comments:
  PATCH 3/6: s,channel,primary_channel;
  PATCH 4/6: add a forward declaration instead of moving code around;
  PATCH 6/6: fix an off-by-one
- Change the algorithm in PATCH 6/6:
  Instead of a simple round robin we first try to find a (sub)channel with
  the current_cpu == target_cpu and we fallback to a round robin when we fail
  to find one.

K. Y., Dexuan, can you please give it a spin in various testing environments
you have? Thanks!

Original description:

This series is a continuation of the "Drivers: hv: vmbus: Use a round-robin
algorithm for picking the outgoing channel" work. It is supposed to bring two
significant changes:
1) Subchannels for a channel are distributed evenly across all vcpus we have.
   Currently we try to distribute all channels (including subchannels) across
   all vcpus, this approach doesn't guarantee that the particular channel's
   subchannels will be distributed in the same way as we process all offer
   requests in some random order. (Patch 05)
2) Channel picking based on the current vcpu is dropped from
   vmbus_get_outgoing_channel() in favor of a fair round robin. (Patch 06) (this
   is not true anymore, see 'Changes').

Patches 01 - 04 are cleanup/refactoring.

Vitaly Kuznetsov (6):
  Drivers: hv: vmbus: unify calls to percpu_channel_enq()
  Drivers: hv: vmbus: briefly comment num_sc and next_oc
  Drivers: hv: vmbus: decrease num_sc on subchannel removal
  Drivers: hv: vmbus: move init_vp_index() call to vmbus_process_offer()
  Drivers: hv: vmbus: distribute subchannels among all vcpus
  Drivers: hv: vmbus: improve selection of an outgoing channel

 drivers/hv/channel_mgmt.c | 127 ++++++++++++++++++++++++++--------------------
 include/linux/hyperv.h    |  12 +++--
 2 files changed, 80 insertions(+), 59 deletions(-)

-- 
1.9.3

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/