AuxXxilium/linux_dsm_epyc7002
1
0
Fork 0
mirror of https://github.com/AuxXxilium/linux_dsm_epyc7002.git synced 2024-11-30 13:46:47 +07:00
Code Issues Actions Packages Projects Releases Wiki Activity

vmbus: only reschedule tasklet if time limit exceeded

Browse Source 
The change to reschedule tasklet if more data arrives in ring buffer
can cause performance regression if host timing is such that the
next response happens in small window.

Go back to a modified version of the original looping behavior.
If the race occurs in a small time, then loop. But if the tasklet
has been running for a long interval due to flood, then reschedule
the tasklet to allow migration to ksoftirqd.

Signed-off-by: Stephen Hemminger <sthemmin@microsoft.com>
Signed-off-by: K. Y. Srinivasan <kys@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This commit is contained in:
Stephen Hemminger 2017-03-04 18:27:10 -07:00 committed by Greg Kroah-Hartman
parent c37235cce3
commit ada6eb1113
1 changed files with 33 additions and 30 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

49
drivers/hv/connection.c
View File

@ -296,19 +296,29 @@ struct vmbus_channel *relid2channel(u32 relid)
/*
* vmbus_on_event - Process a channel event notification
*
* For batched channels (default) optimize host to guest signaling
* by ensuring:
* 1. While reading the channel, we disable interrupts from host.
* 2. Ensure that we process all posted messages from the host
* before returning from this callback.
* 3. Once we return, enable signaling from the host. Once this
* state is set we check to see if additional packets are
* available to read. In this case we repeat the process.
* If this tasklet has been running for a long time
* then reschedule ourselves.
*/
void vmbus_on_event(unsigned long data)
{
struct vmbus_channel *channel = (void *) data;
unsigned long time_limit = jiffies + 2;
do {
void (*callback_fn)(void *);
/*
* A channel once created is persistent even when there
* is no driver handling the device. An unloading driver
* sets the onchannel_callback to NULL on the same CPU
* as where this interrupt is handled (in an interrupt context).
* Thus, checking and invoking the driver specific callback takes
* care of orderly unloading of the driver.
/* A channel once created is persistent even when
* there is no driver handling the device. An
* unloading driver sets the onchannel_callback to NULL.
*/
callback_fn = READ_ONCE(channel->onchannel_callback);
if (unlikely(callback_fn == NULL))
@ -316,25 +326,18 @@ void vmbus_on_event(unsigned long data)
(*callback_fn)(channel->channel_callback_context);
if (channel->callback_mode == HV_CALL_BATCHED) {
/*
* This callback reads the messages sent by the host.
* We can optimize host to guest signaling by ensuring:
* 1. While reading the channel, we disable interrupts from
* host.
* 2. Ensure that we process all posted messages from the host
* before returning from this callback.
* 3. Once we return, enable signaling from the host. Once this
* state is set we check to see if additional packets are
* available to read. In this case we repeat the process.
*/
if (hv_end_read(&channel->inbound) != 0) {
hv_begin_read(&channel->inbound);
if (channel->callback_mode != HV_CALL_BATCHED)
return;
if (likely(hv_end_read(&channel->inbound) == 0))
return;
hv_begin_read(&channel->inbound);
} while (likely(time_before(jiffies, time_limit)));
/* The time limit (2 jiffies) has been reached */
tasklet_schedule(&channel->callback_event);
}
}
}
/*
* vmbus_post_msg - Send a msg on the vmbus's message connection