Re: [PATCH 2.6.16-mm1 1/2] sched_domain: handle kmalloc failure

[Andrew Morton]

Srivatsa Vaddagiri <vatsa@xxxxxxxxxx> wrote:
>
> On Sat, Mar 25, 2006 at 06:06:05PM -0800, Andrew Morton wrote:
> > This is rather ugly, sorry.
> 
> That was about my reaction too when I was going thr'
> build_sched_domains()!
> 
> > So if the kmalloc failed we'll try to limp along without load balancing?
> 
> Not exactly. We will still load balance at lower domains (between
> threads of a CPU & between CPUs of a node) that dont require any memory
> allocation.
> 
> > I think it would be better to free any thus-far allocated memory and to
> > fail the whole thing.
> 
> This would result in absolutely no load balancing (even for domain
> levels which didnt need any memory allocation - like at threads-of-a-cpu
> level). Is that acceptable?
> 
> > Returning void from build_sched_domains was wrong.
> 
> If we decide to return an error, then it has to be percolated all the
> way down (for ex: update_cpu_domains should now have to return an error
> too if partition_sched_domains returns an error)?

Well, when is this code called?  It would be at boot time, in which case
the allocations will succeed (if not, the boot fails) or at cpu/node
hot-add, in which case the appropriate response is to fail to bring up the
new cpu/node.

It's better to send the administrator back to work out why we ran out of
memory than to appear to have brought the new cpu/node online, only to have
it run funny.

I think?

> > build_sched_domains() should be static and __cpuinit, btw.
> 
> Ok ..Will take care of that in the next version of the patch.
> 

umm, it's probably best to not bother.  I think Ashok is looking into all
the memory we're presently wasting on non-cpu_hotplug builds.  There's
quite a lot in there.

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