From: Paul Jackson <pj@sgi.com>
To: akpm@osdl.org
Cc: mel@csn.ul.ie, linux-kernel@vger.kernel.org, dino@in.ibm.com,
jschopp@austin.ibm.com, Simon.Derr@bull.net, torvalds@osdl.org,
haveblue@us.ibm.com
Subject: Re: [PATCH 0/4] cpusets mems_allowed constrain GFP_KERNEL, oom killer
Date: Tue, 6 Sep 2005 01:08:22 -0700 [thread overview]
Message-ID: <20050906010822.5cb635c0.pj@sgi.com> (raw)
In-Reply-To: <20050901090853.18441.24035.sendpatchset@jackhammer.engr.sgi.com>
Andrew,
Please throw away the following 4 patches in 2.6.13-mm1:
cpusets-oom_kill-tweaks.patch
cpusets-new-__gfp_hardwall-flag.patch
cpusets-formalize-intermediate-gfp_kernel-containment.patch
cpusets-confine-oom_killer-to-mem_exclusive-cpuset.patch
You will see almost the same patches come back at you, in another
week, after I first send some patches to rework handling the global
cpuset semaphore cpuset_sem.
My code reading leads me to think there is a rare lockup possibility
here, where a task already holding cpuset_sem could try to get it
again in the new cpuset_zone_allowed() code.
Only systems actively manipulating cpusets have any chance of seeing
this.
--
I won't rest till it's the best ...
Programmer, Linux Scalability
Paul Jackson <pj@sgi.com> 1.925.600.0401
next prev parent reply other threads:[~2005-09-06 8:09 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-09-01 9:08 [PATCH 0/4] cpusets mems_allowed constrain GFP_KERNEL, oom killer Paul Jackson
2005-09-01 9:08 ` [PATCH 1/4] cpusets oom_kill tweaks Paul Jackson
2005-09-01 9:39 ` Coywolf Qi Hunt
2005-09-01 9:58 ` Paul Jackson
2005-09-01 10:49 ` Coywolf Qi Hunt
2005-09-01 9:09 ` [PATCH 2/4] cpusets new __GFP_HARDWALL flag Paul Jackson
2005-09-01 9:09 ` [PATCH 3/4] cpusets formalize intermediate GFP_KERNEL containment Paul Jackson
2005-09-01 9:09 ` [PATCH 4/4] cpusets confine oom_killer to mem_exclusive cpuset Paul Jackson
2005-09-06 8:08 ` Paul Jackson [this message]
2005-09-06 22:29 ` [PATCH 0/4] cpusets mems_allowed constrain GFP_KERNEL, oom killer 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=20050906010822.5cb635c0.pj@sgi.com \
--to=pj@sgi.com \
--cc=Simon.Derr@bull.net \
--cc=akpm@osdl.org \
--cc=dino@in.ibm.com \
--cc=haveblue@us.ibm.com \
--cc=jschopp@austin.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mel@csn.ul.ie \
--cc=torvalds@osdl.org \
/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.