Re: [PATCH 19/40] autonuma: alloc/free/init sched_autonuma

[Andrea Arcangeli]

Hi Konrad,

On Sat, Jun 30, 2012 at 01:10:01AM -0400, Konrad Rzeszutek Wilk wrote:
> On Thu, Jun 28, 2012 at 02:55:59PM +0200, Andrea Arcangeli wrote:
> > This is where the dynamically allocated sched_autonuma structure is
> > being handled.
> > 
> > The reason for keeping this outside of the task_struct besides not
> > using too much kernel stack, is to only allocate it on NUMA
> > hardware. So the not NUMA hardware only pays the memory of a pointer
> > in the kernel stack (which remains NULL at all times in that case). 
> 
> .. snip..
> > +	if (unlikely(alloc_task_autonuma(tsk, orig, node)))
> > +		/* free_thread_info() undoes arch_dup_task_struct() too */
> > +		goto out_thread_info;
> >  
> 
> That looks (without seeing the implementation) and from reading the git
> commit, like that on non-NUMA machines it would fail - and end up
> stop the creation of a task.

On not NUMA systems or if you boot with noautonuma, this does nothing
but returns 0 (if CONFIG_AUTONUMA=n it returns 0 at build time so the
above block is discarded by gcc). It can only fail when AutoNUMA is
enabled on real NUMA hardware, when it does something but you run OOM
(likely also triggering oom killer and stuff but it must handle the
OOM as every other kernel allocation or the whole kernel becomes OOM
deadlock prone).

> 
> Perhaps a better name for the function: alloc_always_task_autonuma
> since the function (at least from the description of this patch) will
> always succeed. Perhaps even remove the:
> "if unlikely(..)" bit?

It will not always succeed and it will not always allocate.
--
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/