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 en
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 th
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 num
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 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, bu
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 cal
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 flags
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 library
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 pu
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
> 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 licen
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 o
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 m
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 w
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 cha
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 rem
18 matches
Mail list logo
