On Thu, 1 Nov 2007, Paul Jackson wrote:
> A library such as libnuma can set them, yes, but not everyone uses
> libnuma. Basically everyone uses the standard C library, glibc, which
> has the system call wrappers, but these wrappers should not be setting
> optional flags.
>
I think what would
On Thu, 1 Nov 2007, Paul Jackson wrote:
> We were discussing libnuma here, not glibc. The system call wrappers
> are in glibc. System call wrappers should not be setting optional
> flags. They should just make the system call -- do whatever magic it
> takes to get the provided arguments into
On Wed, 31 Oct 2007, Paul Jackson wrote:
> With the mode bit as in my patch, there are fewer places in the user
> code that have to be gotten just right. With your way, each and
> every mbind and *_mempolicy call has to be hacked with the new flag
> if one is going to use the new nodemask bit
On Wed, 31 Oct 2007, Paul Jackson wrote:
> The basic reason that I went with an additional per-task modal
> state, rather than a modal flag for each mbind, set_mempolicy and
> get_mempolicy call was to reduce the likely rate of bugs in user
> level C code using this API.
>
I think it may be
On Thu, 1 Nov 2007, Paul Jackson wrote:
> Christoph wrote:
> > The library interface can set flags to modify behavior.
>
> A library such as libnuma can set them, yes, but not everyone uses
> libnuma. Basically everyone uses the standard C library, glibc, which
> has the system call wrappers,
On Thu, 2007-11-01 at 10:26 -0700, Paul Jackson wrote:
> Christoph wrote:
> > The library interface can set flags to modify behavior.
>
> A library such as libnuma can set them, yes, but not everyone uses
> libnuma. Basically everyone uses the standard C library, glibc, which
> has the system
Christoph wrote:
> The library interface can set flags to modify behavior.
A library such as libnuma can set them, yes, but not everyone uses
libnuma. Basically everyone uses the standard C library, glibc, which
has the system call wrappers, but these wrappers should not be setting
optional
On Thu, 1 Nov 2007, Paul Jackson wrote:
> > > Forcing coders to specify the same detail in multiple places, when
> > > there is no way to validate their consistency, doesn't force them
> > > to think or do it right. It increases the error rate due to
> >
> > There are always wrappers for system
Christoph, replying to pj:
> > Wrong. It has not received wide publication yet, but it has been
> > provided to various others under LGPL license.
>
> The last version that I remember was for 2.4.x.
You might be recalling something called libcpumemset, which is about
five years old. The
On Wed, 31 Oct 2007, Paul Jackson wrote:
> > You are managing it in the task struct. No need to. libnuma can handle it.
>
> No - as noted, not all mempolicy system calls go via libnuma.
Well then show me.
> > No current version of libcpuset is available.
>
> Wrong. It has not received wide
On Wed, 31 Oct 2007, Paul Jackson wrote:
> David R - is your use of the mbind and *_mempolicy system calls
> via libnuma, or direct system calls?
>
I hope to be able to use libnuma exclusively once your fix is in place so
that the interleaving behaves the way we want while attached to
On Wed, 31 Oct 2007, Paul Jackson wrote:
David R - is your use of the mbind and *_mempolicy system calls
via libnuma, or direct system calls?
I hope to be able to use libnuma exclusively once your fix is in place so
that the interleaving behaves the way we want while attached to a
On Wed, 31 Oct 2007, Paul Jackson wrote:
You are managing it in the task struct. No need to. libnuma can handle it.
No - as noted, not all mempolicy system calls go via libnuma.
Well then show me.
No current version of libcpuset is available.
Wrong. It has not received wide
Christoph, replying to pj:
Wrong. It has not received wide publication yet, but it has been
provided to various others under LGPL license.
The last version that I remember was for 2.4.x.
You might be recalling something called libcpumemset, which is about
five years old. The library
On Thu, 1 Nov 2007, Paul Jackson wrote:
Forcing coders to specify the same detail in multiple places, when
there is no way to validate their consistency, doesn't force them
to think or do it right. It increases the error rate due to
There are always wrappers for system calls. The
Christoph wrote:
The library interface can set flags to modify behavior.
A library such as libnuma can set them, yes, but not everyone uses
libnuma. Basically everyone uses the standard C library, glibc, which
has the system call wrappers, but these wrappers should not be setting
optional
On Thu, 2007-11-01 at 10:26 -0700, Paul Jackson wrote:
Christoph wrote:
The library interface can set flags to modify behavior.
A library such as libnuma can set them, yes, but not everyone uses
libnuma. Basically everyone uses the standard C library, glibc, which
has the system call
On Thu, 1 Nov 2007, Paul Jackson wrote:
Christoph wrote:
The library interface can set flags to modify behavior.
A library such as libnuma can set them, yes, but not everyone uses
libnuma. Basically everyone uses the standard C library, glibc, which
has the system call wrappers, but
On Wed, 31 Oct 2007, Paul Jackson wrote:
The basic reason that I went with an additional per-task modal
state, rather than a modal flag for each mbind, set_mempolicy and
get_mempolicy call was to reduce the likely rate of bugs in user
level C code using this API.
I think it may be more
On Wed, 31 Oct 2007, Paul Jackson wrote:
With the mode bit as in my patch, there are fewer places in the user
code that have to be gotten just right. With your way, each and
every mbind and *_mempolicy call has to be hacked with the new flag
if one is going to use the new nodemask bit
On Thu, 1 Nov 2007, Paul Jackson wrote:
We were discussing libnuma here, not glibc. The system call wrappers
are in glibc. System call wrappers should not be setting optional
flags. They should just make the system call -- do whatever magic it
takes to get the provided arguments into the
On Thu, 1 Nov 2007, Paul Jackson wrote:
A library such as libnuma can set them, yes, but not everyone uses
libnuma. Basically everyone uses the standard C library, glibc, which
has the system call wrappers, but these wrappers should not be setting
optional flags.
I think what would end up
> You are managing it in the task struct. No need to. libnuma can handle it.
No - as noted, not all mempolicy system calls go via libnuma.
> No current version of libcpuset is available.
Wrong. It has not received wide publication yet, but it has been
provided to various others under LGPL
On Wed, 31 Oct 2007, Paul Jackson wrote:
> Christoph, replying to pj:
> > > Well, the mpol_nodemask_mode already is char. So I guess you're
> > > asking if we should change 'policy' to type char as well.
> >
> > Right.
>
> Ok - but why?
>
> I don't see that it matters whether policy is short
Christoph, replying to pj:
> > Well, the mpol_nodemask_mode already is char. So I guess you're
> > asking if we should change 'policy' to type char as well.
>
> Right.
Ok - but why?
I don't see that it matters whether policy is short or char.
> > > Could we shorten the mpol_nodemask_mode to
On Wed, 31 Oct 2007, Paul Jackson wrote:
> > Make both policy and the mode char?
>
> Well, the mpol_nodemask_mode already is char. So I guess you're
> asking if we should change 'policy' to type char as well.
Right.
> > Could we shorten the mpol_nodemask_mode to mode?
>
> Huh - I don't know
Christoph wrote:
> > short policy; /* See MPOL_* above */
> > + char mpol_nodemask_mode; /* See MPOL_MODE_* above; union c below */
>
> Make both policy and the mode char?
Well, the mpol_nodemask_mode already is char. So I guess you're
asking if we should change 'policy' to type char as
On Tue, 30 Oct 2007, Paul Jackson wrote:
> #include
> @@ -64,13 +72,18 @@ struct mm_struct;
> struct mempolicy {
> atomic_t refcnt;
> short policy; /* See MPOL_* above */
> + char mpol_nodemask_mode; /* See MPOL_MODE_* above; union c below */
Make both policy and the mode
On Tue, 30 Oct 2007, Paul Jackson wrote:
#include linux/mmzone.h
@@ -64,13 +72,18 @@ struct mm_struct;
struct mempolicy {
atomic_t refcnt;
short policy; /* See MPOL_* above */
+ char mpol_nodemask_mode; /* See MPOL_MODE_* above; union c below */
Make both policy and the
Christoph wrote:
short policy; /* See MPOL_* above */
+ char mpol_nodemask_mode; /* See MPOL_MODE_* above; union c below */
Make both policy and the mode char?
Well, the mpol_nodemask_mode already is char. So I guess you're
asking if we should change 'policy' to type char as well.
On Wed, 31 Oct 2007, Paul Jackson wrote:
Make both policy and the mode char?
Well, the mpol_nodemask_mode already is char. So I guess you're
asking if we should change 'policy' to type char as well.
Right.
Could we shorten the mpol_nodemask_mode to mode?
Huh - I don't know what
Christoph, replying to pj:
Well, the mpol_nodemask_mode already is char. So I guess you're
asking if we should change 'policy' to type char as well.
Right.
Ok - but why?
I don't see that it matters whether policy is short or char.
Could we shorten the mpol_nodemask_mode to mode?
On Wed, 31 Oct 2007, Paul Jackson wrote:
Christoph, replying to pj:
Well, the mpol_nodemask_mode already is char. So I guess you're
asking if we should change 'policy' to type char as well.
Right.
Ok - but why?
I don't see that it matters whether policy is short or char.
It
You are managing it in the task struct. No need to. libnuma can handle it.
No - as noted, not all mempolicy system calls go via libnuma.
No current version of libcpuset is available.
Wrong. It has not received wide publication yet, but it has been
provided to various others under LGPL
From: Paul Jackson <[EMAIL PROTECTED]>
RFC only so far - has been built and booted, but has received
almost no testing.
Add a second choice for how node numbers are interpreted and returned
by the NUMA memory policy system calls mbind, set_mempolicy and
get_mempolicy.
The original choice
From: Paul Jackson [EMAIL PROTECTED]
RFC only so far - has been built and booted, but has received
almost no testing.
Add a second choice for how node numbers are interpreted and returned
by the NUMA memory policy system calls mbind, set_mempolicy and
get_mempolicy.
The original choice
36 matches
Mail list logo
