Drawback of polling in kernel sensor driver

Question

I have a sensor driver, which instead of processing interrupts does poll of gyroscope and accelerometer every 5 ms, with help of workqueues.

static void  sensor_delaywork_func(struct work_struct *work)
{
        struct delayed_work *delaywork = container_of(work, struct delayed_work, work);
        struct sensor_private_data *sensor = container_of(delaywork, struct sensor_private_data, delaywork);
        struct i2c_client *client = sensor->client;
        int result;

        mutex_lock(&sensor->sensor_mutex);
        result = sensor->ops->report(client);
        if (result < 0)
                dev_err(&client->dev, "%s: Get data failed\n", __func__);
        mutex_unlock(&sensor->sensor_mutex);

        if ((!sensor->pdata->irq_enable) && (sensor->stop_work == 0))
                schedule_delayed_work(&sensor->delaywork, msecs_to_jiffies(sensor->pdata->poll_delay_ms));
}

The problem is - under heavy load kworker/* threads get preempted and receive less cpu so the amount of generated input events drops from 200 till 170-180 per second.

What really helps - setting higher (rt) priorities for kworker/* threads with chrt for example.

But what is the correct way to rework it in kernel to always have 200 events under any circumstances?

High priority tasklets can not sleep for example so it doesn't seem like a way for implementation. Creating inside driver an own kernel thread with high priority seems like pretty much hack. Any suggestions?