On 9/3/2016 11:31 AM, Frederic Weisbecker wrote:
On Tue, Aug 30, 2016 at 02:17:27PM -0400, Chris Metcalf wrote:
On 8/30/2016 1:36 PM, Chris Metcalf wrote:
See the other thread with Peter Z for the longer discussion of this.
At this point I'm leaning towards replacing the set_tsk_need_resched() with
set_current_state(TASK_INTERRUPTIBLE);
schedule();
__set_current_state(TASK_RUNNING);
I don't see how that helps. What will wake the thread up except a signal?
The answer is that the scheduler will keep bringing us back to this
point (either after running another runnable task if there is one,
or else just returning to this point immediately without doing a
context switch), and we will then go around the "prepare exit to
userspace" loop and perhaps discover that enough time has gone
by that the last dyntick interrupt has triggered and the kernel has
quiesced the dynticks. At that point we stop calling schedule()
over and over and can return normally to userspace.
Oops, you're right that if I set TASK_INTERRUPTIBLE, then if I call
schedule(), I never get control back. So I don't want to do that.
I suppose I could do a schedule_timeout() here instead and try
to figure out how long to wait for the next dyntick. But since we
don't expect anything else running on the core anyway, it seems
like we are probably working too hard at this point. I don't think
it's worth it just to go into the idle task and (possibly) save some
power for a few microseconds.
The more I think about this, the more I think I am micro-optimizing
by trying to poke the scheduler prior to some external thing setting
need_resched, so I think the thing to do here is in fact, nothing.
Exactly, I fear there is nothing you can do about that.
I won't worry about rescheduling but will just continue going around
the prepare-exit-to-userspace loop until the last dyn tick fires.
You mean waiting in prepare-exit-to-userspace until the last tick fires?
I'm not sure it's a good idea either, this could take ages, it could as
well never happen.
If you don't mind, let's take this to the other thread discussing what to do
at return-to-userspace time:
https://lkml.kernel.org/r/440e20d1-441a-3228-6b37-6e71e9fce47c@xxxxxxxxxxxx
In general, I think if your task ends up waiting forever for the dyntick to
stop, with the approach suggested in that thread you will at least be
able to tell more easily, since the core will be running the idle task and
your task will be waiting on a dyntick-specific completion.
I'd rather say that if we are in signal mode, fire such, otherwise just
return to userspace. If there is a tick, it means that the environment is
not suitable for isolation anyway.
True if there is an ongoing tick, but not if the tick is about to stop and we just need
to wait for the last tick to fire.
--
Chris Metcalf, Mellanox Technologies
http://www.mellanox.com
--
To unsubscribe from this list: send the line "unsubscribe linux-api" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
