From: Andrew Morton <akpm@osdl.org>
To: vatsa@in.ibm.com
Cc: nickpiggin@yahoo.com.au, mingo@elte.hu,
suresh.b.siddha@intel.com, pj@sgi.com, hawkes@sgi.com,
linux-kernel@vger.kernel.org, dino@in.ibm.com
Subject: Re: [PATCH 2.6.16-mm1 1/2] sched_domain: handle kmalloc failure
Date: Sat, 25 Mar 2006 18:44:41 -0800 [thread overview]
Message-ID: <20060325184441.0f6ba5bc.akpm@osdl.org> (raw)
In-Reply-To: <20060326024039.GA2998@in.ibm.com>
Srivatsa Vaddagiri <vatsa@in.ibm.com> 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.
next prev parent reply other threads:[~2006-03-26 2:48 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-03-25 8:27 Srivatsa Vaddagiri
2006-03-26 2:06 ` Andrew Morton
2006-03-26 2:40 ` Srivatsa Vaddagiri
2006-03-26 2:44 ` Andrew Morton [this message]
2006-03-26 3:03 ` Nick Piggin
2006-03-26 3:38 ` Srivatsa Vaddagiri
2006-03-26 4:10 ` Paul Jackson
2006-03-26 3:32 ` Srivatsa Vaddagiri
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20060325184441.0f6ba5bc.akpm@osdl.org \
--to=akpm@osdl.org \
--cc=dino@in.ibm.com \
--cc=hawkes@sgi.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=nickpiggin@yahoo.com.au \
--cc=pj@sgi.com \
--cc=suresh.b.siddha@intel.com \
--cc=vatsa@in.ibm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Powered by JetHome