There are some 21 mentions of 'manage_mutex' in the comments of
kernel/cpuset.c remaining after this patch is applied, but no such
mutex exists anymore.
Could you update kernel/cpuset.c comments, Paul M., for this and
whatever other changes apply ?
--
I won't rest till it's
On 9/29/07, Paul Jackson [EMAIL PROTECTED] wrote:
Paul M:
This patch doesn't build for me in the following case. If I apply the
rest of the containersv11 patches, it builds, but if I happen to bisect
into this set of patches having applied only:
These patches weren't the normal style of
On 9/29/07, Paul Jackson [EMAIL PROTECTED] wrote:
There are some 21 mentions of 'manage_mutex' in the comments of
kernel/cpuset.c remaining after this patch is applied, but no such
mutex exists anymore.
Oops, sorry - fixing this is on my todo list.
Paul
fixing this is on my todo list.
thanks!
--
I won't rest till it's the best ...
Programmer, Linux Scalability
Paul Jackson [EMAIL PROTECTED] 1.925.600.0401
___
Containers mailing list
[EMAIL
On Sun, 30 Sep 2007 00:10:18 -0700 Paul Menage [EMAIL PROTECTED] wrote:
On 9/29/07, Paul Jackson [EMAIL PROTECTED] wrote:
Paul M:
This patch doesn't build for me in the following case. If I apply the
rest of the containersv11 patches, it builds, but if I happen to bisect
into this set
Andrew wrote:
And I think that's OK, because we don't care about git bisectability with
CONFIG_CGROUPS=y (I think?) Anyone who is bisecting through the middle of
the containers patch series is not searching for a containers problem, so
they can just configure it all off.
Ok - I guess.
In
On Sun, 30 Sep 2007 02:15:36 -0700 Paul Jackson [EMAIL PROTECTED] wrote:
Andrew wrote:
And I think that's OK, because we don't care about git bisectability with
CONFIG_CGROUPS=y (I think?) Anyone who is bisecting through the middle of
the containers patch series is not searching for a
Andrew wrote:
so when
their bisection cursor moves within or after the cgroups patches, they'll
still have CONFIG_CGROUPS=n. Serendipity.
Unless it's one of the configs that enables cgroups by default, thanks
to the patch:
task-containers-enable-containers-by-default-in-some-configs.patch
Eric W. Biederman wrote:
Patrick McHardy [EMAIL PROTECTED] writes:
Maybe I can save you some time: we used to do down_trylock()
for the rtnl mutex, so senders would simply return if someone
else was already processing the queue *or* the rtnl was locked
for some other reason. In the first case
KAMEZAWA Hiroyuki wrote:
An experimental patch.
This patch adds an interface to uncharge all pages in memory cgroup if
no tasks are in it. By this, a user can remove cgroup by 'rmdir'.
To uncharge all remaing pages in cgrop, echo -n 0 to memory.control_type.
(Just for test, please advise
Hi, thank you for review.
On Mon, 01 Oct 2007 09:46:02 +0530
Balbir Singh [EMAIL PROTECTED] wrote:
@@ -424,17 +424,80 @@ void mem_cgroup_uncharge(struct page_cgr
if (atomic_dec_and_test(pc-ref_cnt)) {
page = pc-page;
lock_page_cgroup(page);
- mem =
11 matches
Mail list logo
