Serge E. Hallyn wrote:
>
> But note that in either case we need to deal with a bunch of locking.
> So getting back to Pierre's patchset, IIRC 1-8 are cleanups worth
> doing no matter 1. 9-11 sound like they are contentuous until
> we decide whether we want to go with a create_with_id() type
Serge E. Hallyn wrote:
But note that in either case we need to deal with a bunch of locking.
So getting back to Pierre's patchset, IIRC 1-8 are cleanups worth
doing no matter 1. 9-11 sound like they are contentuous until
we decide whether we want to go with a create_with_id() type
Quoting Oren Laadan ([EMAIL PROTECTED]):
>
>
> Serge E. Hallyn wrote:
>> Quoting Oren Laadan ([EMAIL PROTECTED]):
>>> I strongly second Kirill on this matter.
>>>
>>> IMHO, we should _avoid_ as much as possible exposing internal kernel
>>> state to applications, unless a _real_ need for it is
Serge E. Hallyn wrote:
Quoting Oren Laadan ([EMAIL PROTECTED]):
I strongly second Kirill on this matter.
IMHO, we should _avoid_ as much as possible exposing internal kernel
state to applications, unless a _real_ need for it is _clearly_
demonstrated. The reasons for this are quite obvious.
Lee wrote:
> Also, your cpuset/mempolicy work will probably need to undo the
> unconditional masking in contextualize_policy() and/or save the original
> node mask somewhere...
Yeah, something like that ... just a small matter of code.
--
I won't rest till it's the best ...
On Tue, 5 Feb 2008, Lee Schermerhorn wrote:
> The patch I just posted doesn't depend on the numactl changes and seems
> quite minimal to me. I think it cleans up the differences between
> set_mempolicy() and mbind(), as well. However, some may take exception
> to the change in
On Tue, 2008-02-05 at 15:33 -0600, Paul Jackson wrote:
> David wrote:
> > It would be disappointing to see a lot of work done to fix
>
> The suggested patch of KOSAKI Motohiro didn't look like a lot of work to me.
>
> I continue to prefer not to hijack this thread for that other discussion.
>
David wrote:
> It would be disappointing to see a lot of work done to fix
The suggested patch of KOSAKI Motohiro didn't look like a lot of work to me.
I continue to prefer not to hijack this thread for that other discussion.
Just presenting your position and calling it "simple" is misleading.
On Tue, 5 Feb 2008, Paul Jackson wrote:
> David wrote:
> > The more alarming result of these remaps is in the MPOL_BIND case, as
> > we've talked about before. The language in set_mempolicy(2):
>
> You're diving into the middle of a rather involved discussion
> we had on the other various
David wrote:
> The more alarming result of these remaps is in the MPOL_BIND case, as
> we've talked about before. The language in set_mempolicy(2):
You're diving into the middle of a rather involved discussion
we had on the other various patches proposed to extend the
interaction of mempolicy's
On Tue, 5 Feb 2008, Paul Jackson wrote:
> Since any of those future patches only add optional modes
> with new flags, while preserving current behaviour if you
> don't use one of the new flags, therefore the current behavior
> has to work as best it can.
>
There's a subtlety to this issue that
On Tue, 5 Feb 2008, Paul Jackson wrote:
> But that discussion touched on some other long standing deficiencies
> in the way that I had originally glued cpusets and memory policies
> together. The current mechanism doesn't handle changing cpusets very
> well, especially if the number of nodes in
Christoph wrote:
> Can we fix up his patch to address the immediate issue?
Since any of those future patches only add optional modes
with new flags, while preserving current behaviour if you
don't use one of the new flags, therefore the current behavior
has to work as best it can.
Therefore
On Tue, 5 Feb 2008, Lee Schermerhorn wrote:
> Christoph: you are free to ignore any part of this discussion that you
> wish...
Had the impression that we are ignoring Kosaki's fix to the problem. Can
we fix up his patch to address the immediate issue?
--
To unsubscribe from this list: send
Quoting Oren Laadan ([EMAIL PROTECTED]):
>
> I strongly second Kirill on this matter.
>
> IMHO, we should _avoid_ as much as possible exposing internal kernel
> state to applications, unless a _real_ need for it is _clearly_
> demonstrated. The reasons for this are quite obvious.
Hmm, sure, but
On Tue, 2008-02-05 at 10:12 -0800, Christoph Lameter wrote:
> Could we focus on the problem instead of discussion of new patches under
> development?
Christoph: you are free to ignore any part of this discussion that you
wish...
> Can we confirm that what Kosaki sees is a bug?
by definition,
Could we focus on the problem instead of discussion of new patches under
development? Can we confirm that what Kosaki sees is a bug?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
On Tue, 2008-02-05 at 04:51 -0500, Oren Laadan wrote:
> That said, I suggest the following method instead (this is the method
> we use in Zap to determine the desired resource identifier when a new
> resource is allocated; I recall that we had discussed it in the past,
> perhaps the mini-summit in
On Tue, 2008-02-05 at 14:31 +, Mel Gorman wrote:
> On (04/02/08 13:20), Lee Schermerhorn didst pronounce:
> > > > When the kernel behaviour changes and breaks user space then the kernel
> > > > is usually wrong. Cc'ed Lee S. who maintains the kernel code now.
> >
> > The memoryless nodes
On (04/02/08 13:20), Lee Schermerhorn didst pronounce:
> > > When the kernel behaviour changes and breaks user space then the kernel
> > > is usually wrong. Cc'ed Lee S. who maintains the kernel code now.
>
> The memoryless nodes patch series changed a lot of things, so just
> reverting this one
Andrew Morton wrote:
> On Tue, 05 Feb 2008 13:48:17 +0530 Kamalesh Babulal <[EMAIL PROTECTED]> wrote:
>
[snip]
> argh, I'd forgotten about that. You bisected it down to a clearly-innocent
> patch and none of the mm developers appeared interested.
>
> Oh well, it'll probably be in mainline
Hi Paul
> Hopefully this week or next, I will publish this patch proposal.
Great.
at that time, I will join review the patch with presure :)
- kosaki
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info
Lee wrote:
> I don't know the current state of Paul's rework of cpusets and
> mems_allowed. That probably resolves this issue, if he still plans on
> allowing a fully populated mask to indicate interleaving over all
> allowed nodes.
It got a bit stalled out for the last month (my employer had
I strongly second Kirill on this matter.
IMHO, we should _avoid_ as much as possible exposing internal kernel
state to applications, unless a _real_ need for it is _clearly_
demonstrated. The reasons for this are quite obvious.
It isn't strictly necessary to export a new interface in order to
On Tue, 05 Feb 2008 13:48:17 +0530 Kamalesh Babulal <[EMAIL PROTECTED]> wrote:
> The 2.6.24-mm1 kernel panics while bootup on the x86_64 (Dual Core AMD
> Opteron)
> box. This was seen in 2.6.24-rc8-mm1 either
> (http://lkml.org/lkml/2008/1/17/129).
>
> BUG: unable
Hi Andrew,
The 2.6.24-mm1 kernel panics while bootup on the x86_64 (Dual Core AMD Opteron)
box. This was seen in 2.6.24-rc8-mm1 either
(http://lkml.org/lkml/2008/1/17/129).
BUG: unable to handle kernel paging request at 4a78
IP: [] __alloc_pages+0x47/0x337
PGD 0
Oops: [1] SMP
* Sachin P. Sant <[EMAIL PROTECTED]> [2008-02-05 06:33]:
> Bernhard Walle wrote:
>> * Vivek Goyal <[EMAIL PROTECTED]> [2008-02-04 19:38]:
>>
>>> Bernahard, any idea who is the competitor here?
>>>
>> Hm ..., can you boot the kernel without crashkernel= and provide the
>> /proc/iomem?
>>
* Sachin P. Sant [EMAIL PROTECTED] [2008-02-05 06:33]:
Bernhard Walle wrote:
* Vivek Goyal [EMAIL PROTECTED] [2008-02-04 19:38]:
Bernahard, any idea who is the competitor here?
Hm ..., can you boot the kernel without crashkernel= and provide the
/proc/iomem?
Attached is the
Hi Andrew,
The 2.6.24-mm1 kernel panics while bootup on the x86_64 (Dual Core AMD Opteron)
box. This was seen in 2.6.24-rc8-mm1 either
(http://lkml.org/lkml/2008/1/17/129).
BUG: unable to handle kernel paging request at 4a78
IP: [8026c9e4] __alloc_pages+0x47/0x337
PGD 0
On Tue, 05 Feb 2008 13:48:17 +0530 Kamalesh Babulal [EMAIL PROTECTED] wrote:
The 2.6.24-mm1 kernel panics while bootup on the x86_64 (Dual Core AMD
Opteron)
box. This was seen in 2.6.24-rc8-mm1 either
(http://lkml.org/lkml/2008/1/17/129).
BUG: unable to handle kernel paging request
I strongly second Kirill on this matter.
IMHO, we should _avoid_ as much as possible exposing internal kernel
state to applications, unless a _real_ need for it is _clearly_
demonstrated. The reasons for this are quite obvious.
It isn't strictly necessary to export a new interface in order to
Lee wrote:
I don't know the current state of Paul's rework of cpusets and
mems_allowed. That probably resolves this issue, if he still plans on
allowing a fully populated mask to indicate interleaving over all
allowed nodes.
It got a bit stalled out for the last month (my employer had other
Hi Paul
Hopefully this week or next, I will publish this patch proposal.
Great.
at that time, I will join review the patch with presure :)
- kosaki
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
Andrew Morton wrote:
On Tue, 05 Feb 2008 13:48:17 +0530 Kamalesh Babulal [EMAIL PROTECTED] wrote:
[snip]
argh, I'd forgotten about that. You bisected it down to a clearly-innocent
patch and none of the mm developers appeared interested.
Oh well, it'll probably be in mainline tomorrow.
On Tue, 2008-02-05 at 14:31 +, Mel Gorman wrote:
On (04/02/08 13:20), Lee Schermerhorn didst pronounce:
When the kernel behaviour changes and breaks user space then the kernel
is usually wrong. Cc'ed Lee S. who maintains the kernel code now.
The memoryless nodes patch series
On (04/02/08 13:20), Lee Schermerhorn didst pronounce:
When the kernel behaviour changes and breaks user space then the kernel
is usually wrong. Cc'ed Lee S. who maintains the kernel code now.
The memoryless nodes patch series changed a lot of things, so just
reverting this one area
On Tue, 2008-02-05 at 04:51 -0500, Oren Laadan wrote:
That said, I suggest the following method instead (this is the method
we use in Zap to determine the desired resource identifier when a new
resource is allocated; I recall that we had discussed it in the past,
perhaps the mini-summit in
Could we focus on the problem instead of discussion of new patches under
development? Can we confirm that what Kosaki sees is a bug?
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
On Tue, 2008-02-05 at 10:12 -0800, Christoph Lameter wrote:
Could we focus on the problem instead of discussion of new patches under
development?
Christoph: you are free to ignore any part of this discussion that you
wish...
Can we confirm that what Kosaki sees is a bug?
by definition,
Quoting Oren Laadan ([EMAIL PROTECTED]):
I strongly second Kirill on this matter.
IMHO, we should _avoid_ as much as possible exposing internal kernel
state to applications, unless a _real_ need for it is _clearly_
demonstrated. The reasons for this are quite obvious.
Hmm, sure, but this
On Tue, 5 Feb 2008, Lee Schermerhorn wrote:
Christoph: you are free to ignore any part of this discussion that you
wish...
Had the impression that we are ignoring Kosaki's fix to the problem. Can
we fix up his patch to address the immediate issue?
--
To unsubscribe from this list: send the
Christoph wrote:
Can we fix up his patch to address the immediate issue?
Since any of those future patches only add optional modes
with new flags, while preserving current behaviour if you
don't use one of the new flags, therefore the current behavior
has to work as best it can.
Therefore fixes
On Tue, 5 Feb 2008, Paul Jackson wrote:
But that discussion touched on some other long standing deficiencies
in the way that I had originally glued cpusets and memory policies
together. The current mechanism doesn't handle changing cpusets very
well, especially if the number of nodes in the
On Tue, 5 Feb 2008, Paul Jackson wrote:
Since any of those future patches only add optional modes
with new flags, while preserving current behaviour if you
don't use one of the new flags, therefore the current behavior
has to work as best it can.
There's a subtlety to this issue that
David wrote:
The more alarming result of these remaps is in the MPOL_BIND case, as
we've talked about before. The language in set_mempolicy(2):
You're diving into the middle of a rather involved discussion
we had on the other various patches proposed to extend the
interaction of mempolicy's
On Tue, 5 Feb 2008, Paul Jackson wrote:
David wrote:
The more alarming result of these remaps is in the MPOL_BIND case, as
we've talked about before. The language in set_mempolicy(2):
You're diving into the middle of a rather involved discussion
we had on the other various patches
David wrote:
It would be disappointing to see a lot of work done to fix
The suggested patch of KOSAKI Motohiro didn't look like a lot of work to me.
I continue to prefer not to hijack this thread for that other discussion.
Just presenting your position and calling it simple is misleading.
The
On Tue, 2008-02-05 at 15:33 -0600, Paul Jackson wrote:
David wrote:
It would be disappointing to see a lot of work done to fix
The suggested patch of KOSAKI Motohiro didn't look like a lot of work to me.
I continue to prefer not to hijack this thread for that other discussion.
Just
On Tue, 5 Feb 2008, Lee Schermerhorn wrote:
The patch I just posted doesn't depend on the numactl changes and seems
quite minimal to me. I think it cleans up the differences between
set_mempolicy() and mbind(), as well. However, some may take exception
to the change in behavior--silently
Lee wrote:
Also, your cpuset/mempolicy work will probably need to undo the
unconditional masking in contextualize_policy() and/or save the original
node mask somewhere...
Yeah, something like that ... just a small matter of code.
--
I won't rest till it's the best ...
Serge E. Hallyn wrote:
Quoting Oren Laadan ([EMAIL PROTECTED]):
I strongly second Kirill on this matter.
IMHO, we should _avoid_ as much as possible exposing internal kernel
state to applications, unless a _real_ need for it is _clearly_
demonstrated. The reasons for this are quite obvious.
Quoting Oren Laadan ([EMAIL PROTECTED]):
Serge E. Hallyn wrote:
Quoting Oren Laadan ([EMAIL PROTECTED]):
I strongly second Kirill on this matter.
IMHO, we should _avoid_ as much as possible exposing internal kernel
state to applications, unless a _real_ need for it is _clearly_
Sachin P. Sant wrote:
Bernhard Walle wrote:
* Vivek Goyal <[EMAIL PROTECTED]> [2008-02-04 19:38]:
Bernahard, any idea who is the competitor here?
Hm ..., can you boot the kernel without crashkernel= and provide the
/proc/iomem?
Attached is the /proc/iomem output with and without
Hi!
>>> As the namespaces and the "containers" are being integrated in the
>>> kernel, these functionalities may be a first step to implement the
>>> checkpoint/restart of an application: in fact the existing API does not
>>> allow
>>> to specify or to change an ID when creating an IPC,
* Vivek Goyal <[EMAIL PROTECTED]> [2008-02-04 19:38]:
>
> Bernahard, any idea who is the competitor here?
Hm ..., can you boot the kernel without crashkernel= and provide the
/proc/iomem?
Bernhard
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of
On Sat, 2 Feb 2008, Andi Kleen wrote:
> To be honest I've never tried seriously to make 32bit NUMA policy
> (with highmem) work well; just kept it at a "should not break"
> level. That is because with highmem the kernel's choices at
> placing memory are seriously limited anyways so I doubt 32bit
On Mon, Feb 04, 2008 at 09:41:11PM +0530, Sachin P. Sant wrote:
> While trying to configure kdump with 2.6.24-rc8-mm1 [ on a x86-64 box ]
> i ran into this problem. Here is the snippet from dmesg during the
> failure. [ dmesg log attached ]
>
> early_ioremap(000
On Sat, 2008-02-02 at 18:37 +0900, KOSAKI Motohiro wrote:
> Hi Andi,
>
> > > 3. 2.6.24-rc8-mm1 set_mempolicy(2) behavior
> > >3.1 check nodesubset(nodemask argument, node_states[N_HIGH_MEMORY])
> > >in mpol_check_policy()
> > >
> >
While trying to configure kdump with 2.6.24-rc8-mm1 [ on a x86-64 box ]
i ran into this problem. Here is the snippet from dmesg during the
failure. [ dmesg log attached ]
early_ioremap(040e, 0002) => -02103442418
early_iounmap(82a0040e, 0002)
early_iore
Pavel Machek wrote:
Hi!
* Patches 9 to 15 propose to add some functionalities, and thus are
submitted here for RFC, about both the interest and their implementation.
These functionalities are:
- Two new control-commands:
. IPC_SETID: to change an IPC's id.
. IPC_SETALL:
Daniel Lezcano wrote:
> Pavel Emelyanov wrote:
>> Kirill Korotaev wrote:
>>> Cedric Le Goater wrote:
Hello Kirill !
Kirill Korotaev wrote:
> Pierre,
>
> my point is that after you've added interface "set IPCID", you'll need
> more and more for checkpointing:
> -
Pavel Emelyanov wrote:
Kirill Korotaev wrote:
Cedric Le Goater wrote:
Hello Kirill !
Kirill Korotaev wrote:
Pierre,
my point is that after you've added interface "set IPCID", you'll need
more and more for checkpointing:
- "create/setup conntrack" (otherwise connections get dropped),
- "set
Kirill Korotaev wrote:
>
> Cedric Le Goater wrote:
>> Hello Kirill !
>>
>> Kirill Korotaev wrote:
>>> Pierre,
>>>
>>> my point is that after you've added interface "set IPCID", you'll need
>>> more and more for checkpointing:
>>> - "create/setup conntrack" (otherwise connections get dropped),
>>>
Pavel Machek wrote:
> Hi!
>
>> * Patches 9 to 15 propose to add some functionalities, and thus are
>> submitted here for RFC, about both the interest and their implementation.
>> These functionalities are:
>> - Two new control-commands:
>> . IPC_SETID: to change an IPC's id.
>> .
Cedric Le Goater wrote:
> Hello Kirill !
>
> Kirill Korotaev wrote:
>> Pierre,
>>
>> my point is that after you've added interface "set IPCID", you'll need
>> more and more for checkpointing:
>> - "create/setup conntrack" (otherwise connections get dropped),
>> - "set task start time" (needed
Pavel Machek wrote:
Hi!
* Patches 9 to 15 propose to add some functionalities, and thus are
submitted here for RFC, about both the interest and their implementation.
These functionalities are:
- Two new control-commands:
. IPC_SETID: to change an IPC's id.
. IPC_SETALL:
Cedric Le Goater wrote:
Hello Kirill !
Kirill Korotaev wrote:
Pierre,
my point is that after you've added interface set IPCID, you'll need
more and more for checkpointing:
- create/setup conntrack (otherwise connections get dropped),
- set task start time (needed for Oracle
Daniel Lezcano wrote:
Pavel Emelyanov wrote:
Kirill Korotaev wrote:
Cedric Le Goater wrote:
Hello Kirill !
Kirill Korotaev wrote:
Pierre,
my point is that after you've added interface set IPCID, you'll need
more and more for checkpointing:
- create/setup conntrack (otherwise connections
While trying to configure kdump with 2.6.24-rc8-mm1 [ on a x86-64 box ]
i ran into this problem. Here is the snippet from dmesg during the
failure. [ dmesg log attached ]
early_ioremap(040e, 0002) = -02103442418
early_iounmap(82a0040e, 0002)
early_ioremap
Pavel Machek wrote:
Hi!
* Patches 9 to 15 propose to add some functionalities, and thus are
submitted here for RFC, about both the interest and their implementation.
These functionalities are:
- Two new control-commands:
. IPC_SETID: to change an IPC's id.
. IPC_SETALL:
* Vivek Goyal [EMAIL PROTECTED] [2008-02-04 19:38]:
Bernahard, any idea who is the competitor here?
Hm ..., can you boot the kernel without crashkernel= and provide the
/proc/iomem?
Bernhard
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a
Pavel Emelyanov wrote:
Kirill Korotaev wrote:
Cedric Le Goater wrote:
Hello Kirill !
Kirill Korotaev wrote:
Pierre,
my point is that after you've added interface set IPCID, you'll need
more and more for checkpointing:
- create/setup conntrack (otherwise connections get dropped),
- set task
On Sat, 2008-02-02 at 18:37 +0900, KOSAKI Motohiro wrote:
Hi Andi,
3. 2.6.24-rc8-mm1 set_mempolicy(2) behavior
3.1 check nodesubset(nodemask argument, node_states[N_HIGH_MEMORY])
in mpol_check_policy()
- check failed when memmoryless node exist.
(i.e
Hi!
As the namespaces and the containers are being integrated in the
kernel, these functionalities may be a first step to implement the
checkpoint/restart of an application: in fact the existing API does not
allow
to specify or to change an ID when creating an IPC, when restarting an
Kirill Korotaev wrote:
Cedric Le Goater wrote:
Hello Kirill !
Kirill Korotaev wrote:
Pierre,
my point is that after you've added interface set IPCID, you'll need
more and more for checkpointing:
- create/setup conntrack (otherwise connections get dropped),
- set task start time (needed
On Sat, 2 Feb 2008, Andi Kleen wrote:
To be honest I've never tried seriously to make 32bit NUMA policy
(with highmem) work well; just kept it at a should not break
level. That is because with highmem the kernel's choices at
placing memory are seriously limited anyways so I doubt 32bit
NUMA
On Mon, Feb 04, 2008 at 09:41:11PM +0530, Sachin P. Sant wrote:
While trying to configure kdump with 2.6.24-rc8-mm1 [ on a x86-64 box ]
i ran into this problem. Here is the snippet from dmesg during the
failure. [ dmesg log attached ]
early_ioremap(040e, 0002
Sachin P. Sant wrote:
Bernhard Walle wrote:
* Vivek Goyal [EMAIL PROTECTED] [2008-02-04 19:38]:
Bernahard, any idea who is the competitor here?
Hm ..., can you boot the kernel without crashkernel= and provide the
/proc/iomem?
Attached is the /proc/iomem output with and without
Hi!
> * Patches 9 to 15 propose to add some functionalities, and thus are
> submitted here for RFC, about both the interest and their implementation.
> These functionalities are:
> - Two new control-commands:
> . IPC_SETID: to change an IPC's id.
> . IPC_SETALL: behaves as
> I have 1 simple question.
> Why do libnuma generate bitpattern of all bit on instead
> check /sys/devices/system/node/has_high_memory nor
> check /sys/devices/system/node/online?
>
> Do you know it?
It's far simpler and cheaper (sysfs is expensive) to do this in the kernel
and besides the
Hi Andi,
> > 3. 2.6.24-rc8-mm1 set_mempolicy(2) behavior
> >3.1 check nodesubset(nodemask argument, node_states[N_HIGH_MEMORY])
> >in mpol_check_policy()
> >
> > -> check failed when memmoryless node exist.
> >(i.e. node_sta
[intentional full quote]
On Sat, Feb 02, 2008 at 05:12:30PM +0900, KOSAKI Motohiro wrote:
> I tested numactl on 2.6.24-rc8-mm1.
> and I found strange behavior.
>
> test method and result.
>
> $ numactl --interleave=all ls
> set_mempolicy: Invalid argument
>
Hi
I tested numactl on 2.6.24-rc8-mm1.
and I found strange behavior.
test method and result.
$ numactl --interleave=all ls
set_mempolicy: Invalid argument
setting interleave mask: Invalid argument
numactl command download from
ftp://ftp.suse.com/pub/people/ak
Hi
I tested numactl on 2.6.24-rc8-mm1.
and I found strange behavior.
test method and result.
$ numactl --interleave=all ls
set_mempolicy: Invalid argument
setting interleave mask: Invalid argument
numactl command download from
ftp://ftp.suse.com/pub/people/ak
[intentional full quote]
On Sat, Feb 02, 2008 at 05:12:30PM +0900, KOSAKI Motohiro wrote:
I tested numactl on 2.6.24-rc8-mm1.
and I found strange behavior.
test method and result.
$ numactl --interleave=all ls
set_mempolicy: Invalid argument
setting interleave mask
Hi Andi,
3. 2.6.24-rc8-mm1 set_mempolicy(2) behavior
3.1 check nodesubset(nodemask argument, node_states[N_HIGH_MEMORY])
in mpol_check_policy()
- check failed when memmoryless node exist.
(i.e. node_states[N_HIGH_MEMORY] of my machine is 0xc)
4. RHEL5.1
I have 1 simple question.
Why do libnuma generate bitpattern of all bit on instead
check /sys/devices/system/node/has_high_memory nor
check /sys/devices/system/node/online?
Do you know it?
It's far simpler and cheaper (sysfs is expensive) to do this in the kernel
and besides the kernel
Hi!
* Patches 9 to 15 propose to add some functionalities, and thus are
submitted here for RFC, about both the interest and their implementation.
These functionalities are:
- Two new control-commands:
. IPC_SETID: to change an IPC's id.
. IPC_SETALL: behaves as IPC_SET,
On Tue, 22 Jan 2008 15:13:58 -0800
Dave Hansen <[EMAIL PROTECTED]> wrote:
> @@ -566,10 +567,26 @@ static void mark_files_ro(struct super_b
> {
> struct file *f;
>
> +retry:
> file_list_lock();
> list_for_each_entry(f, >s_files, f_u.fu_list) {
> - if
* Sudhir Kumar <[EMAIL PROTECTED]> wrote:
> >http://redhat.com/~mingo/x86.git/README
> >
> > does that crash too?
>
> Sorry , unable to do that as the instrunctions at above location do
> not work. Something else I can try ?
hm, those instructions work fine here, if i do them anew. It
Serge E. Hallyn wrote:
> Quoting Pierre Peiffer ([EMAIL PROTECTED]):
>>
>> Serge E. Hallyn wrote:
>>> Quoting [EMAIL PROTECTED] ([EMAIL PROTECTED]):
From: Pierre Peiffer <[EMAIL PROTECTED]>
In order to modify the semundo-list of a task from procfs, we must be able
to
Serge E. Hallyn wrote:
Quoting Pierre Peiffer ([EMAIL PROTECTED]):
Serge E. Hallyn wrote:
Quoting [EMAIL PROTECTED] ([EMAIL PROTECTED]):
From: Pierre Peiffer [EMAIL PROTECTED]
In order to modify the semundo-list of a task from procfs, we must be able
to
work on any target task.
But
On Tue, 22 Jan 2008 15:13:58 -0800
Dave Hansen [EMAIL PROTECTED] wrote:
@@ -566,10 +567,26 @@ static void mark_files_ro(struct super_b
{
struct file *f;
+retry:
file_list_lock();
list_for_each_entry(f, sb-s_files, f_u.fu_list) {
- if
Quoting Pierre Peiffer ([EMAIL PROTECTED]):
>
>
> Serge E. Hallyn wrote:
> > Quoting [EMAIL PROTECTED] ([EMAIL PROTECTED]):
> >> From: Pierre Peiffer <[EMAIL PROTECTED]>
> >>
> >> In order to modify the semundo-list of a task from procfs, we must be able
> >> to
> >> work on any target task.
>
Hello Kirill !
Kirill Korotaev wrote:
Pierre,
my point is that after you've added interface "set IPCID", you'll need more and
more for checkpointing:
- "create/setup conntrack" (otherwise connections get dropped),
- "set task start time" (needed for Oracle checkpointing BTW),
- "set some
On Mon, Jan 28, 2008 at 04:13:00PM +0100, Ingo Molnar wrote:
>
> * Sudhir Kumar <[EMAIL PROTECTED]> wrote:
>
> > I applied all the hot fixes patches but still the bug is there. (crash
> > at early boot).
> >
> > As I replied your earlier mail in which the patch sent by you does not
> > apply
Pierre,
my point is that after you've added interface "set IPCID", you'll need more and
more for checkpointing:
- "create/setup conntrack" (otherwise connections get dropped),
- "set task start time" (needed for Oracle checkpointing BTW),
- "set some statistics counters (e.g. networking or
Kirill Korotaev wrote:
> Why user space can need this API? for checkpointing only?
I would say "at least for checkpointing"... ;) May be someone else may find an
interest about this for something else.
In fact, I'm sure that you have some interest in checkpointing; and thus, you
have probably
Pierre Peiffer wrote:
Nadia Derbey wrote:
[EMAIL PROTECTED] wrote:
From: Pierre Peiffer <[EMAIL PROTECTED]>
semctl_down() takes one unused parameter: semnum.
This patch proposes to get rid of it.
Signed-off-by: Pierre Peiffer <[EMAIL PROTECTED]>
Acked-by: Serge Hallyn <[EMAIL PROTECTED]>
Nadia Derbey wrote:
> [EMAIL PROTECTED] wrote:
>> From: Pierre Peiffer <[EMAIL PROTECTED]>
>>
>> semctl_down() takes one unused parameter: semnum.
>> This patch proposes to get rid of it.
>>
>> Signed-off-by: Pierre Peiffer <[EMAIL PROTECTED]>
>> Acked-by: Serge Hallyn <[EMAIL PROTECTED]>
>> ---
1 - 100 of 452 matches
Mail list logo
