All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andi Kleen <ak@suse.de>
To: Paul Jackson <pj@sgi.com>
Cc: Anton Blanchard <anton@samba.org>,
	akpm@osdl.org, Simon.Derr@bull.net, linux-kernel@vger.kernel.org,
	Andi Kleen <ak@suse.de>,
	IWAMOTO Toshihiro <iwamoto@valinux.co.jp>,
	Dave Hansen <haveblue@us.ibm.com>
Subject: Re: [Patch 4/4] cpusets top mask just online, not all possible
Date: Sat, 11 Sep 2004 20:55:22 +0200	[thread overview]
Message-ID: <20040911185522.GA493@wotan.suse.de> (raw)
In-Reply-To: <20040911100731.2f400271.pj@sgi.com>

On Sat, Sep 11, 2004 at 10:07:31AM -0700, Paul Jackson wrote:
> Cpusets builds up additional data structures, used to manage a tasks CPU
> and Memory placement.  If more CPUs or Memory are added later on,
> cpusets won't know of them nor let you use them.  If CPUs or Memory are
> removed later on, cpusets will still think it is ok to use them, and
> potentially starve a task if that tasks cpuset had been configured to
> _only_ allow using the now departed CPU or Memory.

MPOL_BIND uses direct pointers to zones, the others just node numbers
and fall back to other zones.  Lost node numbers should be pretty easy to 
deal with because there is enough redirection. MPOL_BIND is a bit more
difficult.

My prefered solution would be to never actually remove the zone datastructure,
but just make them zero size when their memory is gone. Then the mempolicies 
could still keep pointers to them, but any allocations will fail.

This may require putting them into different memory though (currently
they are usually in the node itself) 

This should also allow cpumemset to work.

Of course the applications may not be very happy when all the memory
they are allowed to touch is gone, but fixing that is imho more
a high level user space management problem, nothing the kernel
should try to resolve.

-Andi

  parent reply	other threads:[~2004-09-11 18:58 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-09-11  8:28 [Patch 0/4] four small cpuset patches Paul Jackson
2004-09-11  8:28 ` [Patch 1/4] cpusets display allowed masks in proc status Paul Jackson
2004-09-11  8:28 ` [Patch 2/4] cpusets simplify cpus_allowed setting in attach Paul Jackson
2004-09-11  8:28 ` [Patch 3/4] cpusets remove useless validation check Paul Jackson
2004-09-11  8:28 ` [Patch 4/4] cpusets top mask just online, not all possible Paul Jackson
2004-09-11 14:10   ` Anton Blanchard
2004-09-11 17:07     ` Paul Jackson
2004-09-11 17:28       ` Dave Hansen
2004-09-12  2:21         ` Paul Jackson
2004-09-12  4:43           ` Dave Hansen
2004-09-12  5:35             ` Paul Jackson
2004-09-12  5:42             ` Paul Jackson
2004-09-11 17:39       ` Dave Hansen
2004-09-11 18:55       ` Andi Kleen [this message]
2004-09-12  2:29         ` Paul Jackson

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=20040911185522.GA493@wotan.suse.de \
    --to=ak@suse.de \
    --cc=Simon.Derr@bull.net \
    --cc=akpm@osdl.org \
    --cc=anton@samba.org \
    --cc=haveblue@us.ibm.com \
    --cc=iwamoto@valinux.co.jp \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pj@sgi.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.