Re: [LNG] Re: [Query] Ticks happen in pair for NO_HZ_FULL cores ?

[Viresh Kumar]

Adding Ingo/Peter..

On 18 December 2013 20:03, Viresh Kumar <viresh.kumar@xxxxxxxxxx> wrote:
> On 18 December 2013 19:21, Kevin Hilman <khilman@xxxxxxxxxx> wrote:
>> Ah, I see.  So you're basically asking why we can't evaluate whether to
>> turn off the tick more often, for example right after the workqueues are
>> done.  I suppose Frederic may have some views on that, but there's
>> likely additional overhead from those checks as well as that workqueues
>> may not be the only thing keeping us out of NO_HZ.
>
> I see that sched_switch is called at the end most of the times so an check
> there might be useful ?

Wrong time, probably many people on vacation now. But I am working, so
will continue reporting my problems, in case somebody is around :)

My usecase: I am working on making ARM better for Networking servers.
In our usecase we need to isolate few of the cores in our SoC, so that they
run a single user space task per CPU. And userspace will take care of
data plane side of things for them.

Now, we want to use NO_HZ_FULL with CPUSets (And this is what I have
been trying since sometime), so that we don't get any, any interruption on
those cores. They should keep running that task unless that task tries
to switch to kernel space.

I am getting interrupted by few of the workqueues (other than per-cpu
ones). One of them was bdi writeback one, that we discussed earlier.

I have done some work in the past about Power efficient workqueues
(Mentioned by Tejun few mails back), which used to switch those works
on UNBOUND workqueues and so scheduler would decide on the CPU
it want's to queue those works on.

With an idle CPU, it works fine as scheduler doesn't wake up a idle CPU
for servicing that work.

*But wouldn't it make sense if we can tell scheduler that don't queue
these works on a CPU that is running in NO_HZ_FULL mode?*

Also any suggestions on how to get rid of __prandom_timer events on
such CPUs?

Thanks in Advance..

--
viresh
--
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/