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

Hi Johannes and Glauber,

On 07/05/2012 05:09 PM, Johannes Weiner wrote:

quoted

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.

quoted

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, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>