Re: [PATCH 09/40] autonuma: introduce kthread_bind_node()

[Andrea Arcangeli]

Hi Johannes and Glauber,

> On 07/05/2012 05:09 PM, Johannes Weiner wrote:
> > In the very first review iteration of AutoNUMA, Peter argued that the
> > scheduler people want to use this flag in other places where they rely
> > on this thing meaning a single cpu, not a group of them (check out the
> > cpumask test in debug_smp_processor_id() in lib/smp_processor_id.c).

I already suggested to add a new bitflag for that future optimization,
when adding the future code, if that optimization is so worth it.

> > 
> > He also argued that preventing root from rebinding the numa daemons is
> > not critical to this feature at all.  And I have to agree.

It's not critical indeed, it was just a minor reliability
improvement just like it is right now for all other usages.

On Thu, Jul 05, 2012 at 10:33:35PM +0400, Glauber Costa wrote:
> Despite not being a scheduler expert, I'll have to side with that as
> well. The thing I have in mind is: We have people whose usecase depend
> on completely isolating cpus, with nothing but a specialized task
> running on it. For those people, even the hard binding between cpu0 and
> the timer interrupt is a big problem.
> 
> If you force a per-node binding of a kthread, you are basically saying
> that those people are unable to isolate a node. Or else, that they have
> to choose between that, and AutoNUMA. Both are suboptimal choices, to
> say the least.

I'm afraid AutoNUMA in those nanosecond latency setups will be
disabled, so knuma_migrated won't ever have a chance to run in the
first place. I doubt they want to risk to hit on a migration fault,
even if the migration is async with AutoNUMA there's still a chance
for userland to hit on a migration pte. Plus who starts to alter CPU
binding on kernel daemon and remove irqs from cpus, is likely to be
using hard bindings on the userland app too, so not needing AutoNUMA.

However we cannot fell for sure I agree, so your argument of wanting
to isolate the CPU while leaving AutoNUMA enabled is the most
convincing argument so far in favour of stopping setting the flag on
knuma_migrated.

Thanks,
Andrea
--
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/