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'
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
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 be
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 cpum
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 c
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? bitm
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
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
> > deta
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 need
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 y
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
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 t
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
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 t
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 des
15 matches
Mail list logo
