Re: [RFC] bitmap relative operator for mempolicy extensions

2008-02-15 Thread Paul Jackson
Ray wrote: > bitmap_onto? Ah - you were the original person to propose this. Thank-you. > bitmap_read_my_kernel_doc? ;). > Minor suggestion: > + * and the n-th bit of @relmap is the m-th set bit of @relmap. I'll ponder that confusing line - thanks. -- I won't rest till

Re: [RFC] bitmap relative operator for mempolicy extensions

2008-02-15 Thread Paul Jackson
David wrote: > There's also an extra "is" in the description: ah so so -- thanks. -- I won't rest till it's the best ... Programmer, Linux Scalability Paul Jackson <[EMAIL PROTECTED]> 1.940.382.4214 -- To unsubscribe from this list: send the

Re: [RFC] bitmap relative operator for mempolicy extensions

2008-02-15 Thread Paul Jackson
Kosaki-san wrote: > I like bitmap_onto I like it too. And easier to type than bitmap_surjection ;). > relmap could be sparse (which, btw, would have been nice to > have in the example) Good idea. I'll see what I can cook up. Thank-you, sir. -- I won't rest till it's the

Re: [RFC] bitmap relative operator for mempolicy extensions

2008-02-15 Thread Paul Jackson
Andi, responding to Christoph, wrote: > You're saying the kernel should use these relative masks internally? In a conversation with Christoph Thursday afternoon, I got the impression that he liked the idea of using some more compact representation of sparse collections of CPUs (or Nodes) than

Re: [RFC] bitmap relative operator for mempolicy extensions

2008-02-15 Thread Paul Jackson
Andi, responding to Christoph, wrote: You're saying the kernel should use these relative masks internally? In a conversation with Christoph Thursday afternoon, I got the impression that he liked the idea of using some more compact representation of sparse collections of CPUs (or Nodes) than

Re: [RFC] bitmap relative operator for mempolicy extensions

2008-02-15 Thread Paul Jackson
Kosaki-san wrote: I like bitmap_onto I like it too. And easier to type than bitmap_surjection ;). relmap could be sparse (which, btw, would have been nice to have in the example) Good idea. I'll see what I can cook up. Thank-you, sir. -- I won't rest till it's the best

Re: [RFC] bitmap relative operator for mempolicy extensions

2008-02-15 Thread Paul Jackson
David wrote: There's also an extra is in the description: ah so so -- thanks. -- I won't rest till it's the best ... Programmer, Linux Scalability Paul Jackson [EMAIL PROTECTED] 1.940.382.4214 -- To unsubscribe from this list: send the line

Re: [RFC] bitmap relative operator for mempolicy extensions

2008-02-15 Thread Paul Jackson
Ray wrote: bitmap_onto? Ah - you were the original person to propose this. Thank-you. bitmap_read_my_kernel_doc? ;). Minor suggestion: + * and the n-th bit of @relmap is the m-th set bit of @relmap. I'll ponder that confusing line - thanks. -- I won't rest till it's

Re: [RFC] bitmap relative operator for mempolicy extensions

2008-02-14 Thread KOSAKI Motohiro
Hi Ray, > > > i prefer another name [!relative]. > > > > Any suggestions? > > > > I'll give the name some thought myself. > > I like good names, and this is the right > > time to get this one right. > > 'Relative map' implies a constant offset. What you have there is just > a map as relmap

Re: [RFC] bitmap relative operator for mempolicy extensions

2008-02-14 Thread David Rientjes
On Thu, 14 Feb 2008, Ray Lee wrote: > map_bitmap violates your naming convention, bitmap_map isn't all that > clear, bitmap_remap is taken, and while it is one-to-one and onto, I > think calling it bitmap_bijection would lose everyone except the > mathematicians. bitmap_onto? bitmap_map_onto?

Re: [RFC] bitmap relative operator for mempolicy extensions

2008-02-14 Thread Ray Lee
On Thu, Feb 14, 2008 at 8:35 AM, Paul Jackson <[EMAIL PROTECTED]> wrote: > Kosaki-san wrote: > > i prefer another name [!relative]. > > Any suggestions? > > I'll give the name some thought myself. > I like good names, and this is the right > time to get this one right. 'Relative map' implies

Re: [RFC] bitmap relative operator for mempolicy extensions

2008-02-14 Thread Andi Kleen
On Thursday 14 February 2008 21:25:59 Mike Travis wrote: > Christoph Lameter wrote: > > On Thu, 14 Feb 2008, Andi Kleen wrote: > > > >> You're saying the kernel should use these relative masks internally? > > > > There is just some thoughts about this. Did not have time to look into the > >

Re: [RFC] bitmap relative operator for mempolicy extensions

2008-02-14 Thread Mike Travis
Christoph Lameter wrote: > On Thu, 14 Feb 2008, Andi Kleen wrote: > >> You're saying the kernel should use these relative masks internally? > > There is just some thoughts about this. Did not have time to look into the > details. Mike? There are a few places where the entire cpumask is not

Re: [RFC] bitmap relative operator for mempolicy extensions

2008-02-14 Thread Christoph Lameter
On Thu, 14 Feb 2008, Andi Kleen wrote: > You're saying the kernel should use these relative masks internally? There is just some thoughts about this. Did not have time to look into the details. Mike? > That means it would be impossible to run workloads that use the complete > machine because

Re: [RFC] bitmap relative operator for mempolicy extensions

2008-02-14 Thread Andi Kleen
On Thursday 14 February 2008 20:27:59 Christoph Lameter wrote: > Excellent. Relative node masks are a nice feature and may allow us to even > cut down the size of the bitmasks for configurations with large numbers of > nodes. > > Reviewed-by: Christoph Lameter <[EMAIL PROTECTED]> > > ccing

Re: [RFC] bitmap relative operator for mempolicy extensions

2008-02-14 Thread Christoph Lameter
Excellent. Relative node masks are a nice feature and may allow us to even cut down the size of the bitmasks for configurations with large numbers of nodes. Reviewed-by: Christoph Lameter <[EMAIL PROTECTED]> ccing Mike since he may need something similar for cpu masks which are getting a bit

Re: [RFC] bitmap relative operator for mempolicy extensions

2008-02-14 Thread Paul Jackson
Kosaki-san wrote: > i prefer another name [!relative]. Any suggestions? I'll give the name some thought myself. I like good names, and this is the right time to get this one right. -- I won't rest till it's the best ... Programmer, Linux Scalability

Re: [RFC] bitmap relative operator for mempolicy extensions

2008-02-14 Thread KOSAKI Motohiro
Hi Paul, > The following adds one more bitmap operator, with the usual > cpumask and nodemask wrappers. This operator computes one > bitmap relative to another. If the n-th bit in the origin > mask is set, then the m-th bit of the destination mask will > be set, where m is the position of

[RFC] bitmap relative operator for mempolicy extensions

2008-02-14 Thread Paul Jackson
From: Paul Jackson <[EMAIL PROTECTED]> [Beware - never tested, never booted.] The following adds one more bitmap operator, with the usual cpumask and nodemask wrappers. This operator computes one bitmap relative to another. If the n-th bit in the origin mask is set, then the m-th bit of the

[RFC] bitmap relative operator for mempolicy extensions

2008-02-14 Thread Paul Jackson
From: Paul Jackson [EMAIL PROTECTED] [Beware - never tested, never booted.] The following adds one more bitmap operator, with the usual cpumask and nodemask wrappers. This operator computes one bitmap relative to another. If the n-th bit in the origin mask is set, then the m-th bit of the

Re: [RFC] bitmap relative operator for mempolicy extensions

2008-02-14 Thread KOSAKI Motohiro
Hi Paul, The following adds one more bitmap operator, with the usual cpumask and nodemask wrappers. This operator computes one bitmap relative to another. If the n-th bit in the origin mask is set, then the m-th bit of the destination mask will be set, where m is the position of the

Re: [RFC] bitmap relative operator for mempolicy extensions

2008-02-14 Thread Paul Jackson
Kosaki-san wrote: i prefer another name [!relative]. Any suggestions? I'll give the name some thought myself. I like good names, and this is the right time to get this one right. -- I won't rest till it's the best ... Programmer, Linux Scalability

Re: [RFC] bitmap relative operator for mempolicy extensions

2008-02-14 Thread Christoph Lameter
Excellent. Relative node masks are a nice feature and may allow us to even cut down the size of the bitmasks for configurations with large numbers of nodes. Reviewed-by: Christoph Lameter [EMAIL PROTECTED] ccing Mike since he may need something similar for cpu masks which are getting a bit

Re: [RFC] bitmap relative operator for mempolicy extensions

2008-02-14 Thread Andi Kleen
On Thursday 14 February 2008 20:27:59 Christoph Lameter wrote: Excellent. Relative node masks are a nice feature and may allow us to even cut down the size of the bitmasks for configurations with large numbers of nodes. Reviewed-by: Christoph Lameter [EMAIL PROTECTED] ccing Mike since

Re: [RFC] bitmap relative operator for mempolicy extensions

2008-02-14 Thread Christoph Lameter
On Thu, 14 Feb 2008, Andi Kleen wrote: You're saying the kernel should use these relative masks internally? There is just some thoughts about this. Did not have time to look into the details. Mike? That means it would be impossible to run workloads that use the complete machine because you

Re: [RFC] bitmap relative operator for mempolicy extensions

2008-02-14 Thread Andi Kleen
On Thursday 14 February 2008 21:25:59 Mike Travis wrote: Christoph Lameter wrote: On Thu, 14 Feb 2008, Andi Kleen wrote: You're saying the kernel should use these relative masks internally? There is just some thoughts about this. Did not have time to look into the details. Mike?

Re: [RFC] bitmap relative operator for mempolicy extensions

2008-02-14 Thread Mike Travis
Christoph Lameter wrote: On Thu, 14 Feb 2008, Andi Kleen wrote: You're saying the kernel should use these relative masks internally? There is just some thoughts about this. Did not have time to look into the details. Mike? There are a few places where the entire cpumask is not needed.

Re: [RFC] bitmap relative operator for mempolicy extensions

2008-02-14 Thread Ray Lee
On Thu, Feb 14, 2008 at 8:35 AM, Paul Jackson [EMAIL PROTECTED] wrote: Kosaki-san wrote: i prefer another name [!relative]. Any suggestions? I'll give the name some thought myself. I like good names, and this is the right time to get this one right. 'Relative map' implies a constant

Re: [RFC] bitmap relative operator for mempolicy extensions

2008-02-14 Thread David Rientjes
On Thu, 14 Feb 2008, Ray Lee wrote: map_bitmap violates your naming convention, bitmap_map isn't all that clear, bitmap_remap is taken, and while it is one-to-one and onto, I think calling it bitmap_bijection would lose everyone except the mathematicians. bitmap_onto? bitmap_map_onto?

Re: [RFC] bitmap relative operator for mempolicy extensions

2008-02-14 Thread KOSAKI Motohiro
Hi Ray, i prefer another name [!relative]. Any suggestions? I'll give the name some thought myself. I like good names, and this is the right time to get this one right. 'Relative map' implies a constant offset. What you have there is just a map as relmap could be sparse