lkml.org 
[lkml]   [2015]   [Feb]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: RFC: revert 43fa5460fe60
On Tue, 24 Feb 2015 09:55:09 -0500
Jörn Engel <joern@purestorage.com> wrote:

> Hello Steven!
>
> I came across a silly problem that tempted me to revert 43fa5460fe60.
> We had a high-priority realtime thread woken, TIF_NEED_RESCHED was set
> for the running thread and the realtime thread didn't run for >2s.
> Problem was a system call that mapped a ton of device memory and never
> hit a cond_resched() point. Obvious solution is to fix the long-running
> system call.

I'm assuming that you are running a non PREEMPT kernel
(PREEMPT_VOLUNTARY doesn't count). If that's the case, then it is very
much likely that you will hit long latencies. Regardless of this change
or not (you will continue to need to whack-a-mole here).

>
> Applying that solution quickly turns into a game of whack-a-mole. Not
> the worst game in the world and all those moles surely deserve a solid
> hit on the head. But what is annoying in my case is that I had plenty
> of idle cpus during the entire time and the high-priority thread was
> allowed to run anywhere. So if the thread had been moved to a different
> runqueue immediately there would have been zero delay. Sure, the cache
> is semi-cold or the migration may even be cross-package. That is a
> tradeoff we are willing to make and we set the cpumask explicitly that
> way. We want this thread to run quickly, anywhere.
>
> So we could check for currently idle cpus when waking realtime threads.
> If there are any, immediately move the woken thread over. Maybe have a
> check whether the running thread on the current cpu is in a syscall and
> retain current behaviour if not.
>
> Now this is not quite the same as reverting 43fa5460fe60 and I would
> like to verify the idea before I spend time on a patch you would never
> consider merging anyway.

The thing is, the patch you want to revert helped a lot for
CONFIG_PREEMPT kernels. It doesn't make sense to gut a change for a non
CONFIG_PREEMPT kernel as that already suffers huge latencies.

This is considering that you are indeed not running a CONFIG_PREEMPT
kernel, as you stated that it doesn't preempt until it hits a
cond_resched().

-- Steve




\
 
 \ /
  Last update: 2015-02-24 16:41    [W:0.606 / U:0.016 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site