All of lore.kernel.org
 help / color / mirror / Atom feed
From: Srivatsa Vaddagiri <vatsa@in.ibm.com>
To: Andrew Morton <akpm@osdl.org>
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: Sun, 26 Mar 2006 08:10:39 +0530	[thread overview]
Message-ID: <20060326024039.GA2998@in.ibm.com> (raw)
In-Reply-To: <20060325180605.6e5bb4b9.akpm@osdl.org>

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)?

> build_sched_domains() should be static and __cpuinit, btw.

Ok ..Will take care of that in the next version of the patch.

And thanks for the response to the patch!

-- 
Regards,
vatsa

  reply	other threads:[~2006-03-26  2:40 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-03-25  8:27 [PATCH 2.6.16-mm1 1/2] sched_domain: handle kmalloc failure Srivatsa Vaddagiri
2006-03-26  2:06 ` Andrew Morton
2006-03-26  2:40   ` Srivatsa Vaddagiri [this message]
2006-03-26  2:44     ` Andrew Morton
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=20060326024039.GA2998@in.ibm.com \
    --to=vatsa@in.ibm.com \
    --cc=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 \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.