LKML Archive on
help / color / mirror / Atom feed
From: Paul Jackson <>
To: Andi Kleen <>
Subject: Re: [RFC] bitmap relative operator for mempolicy extensions
Date: Fri, 15 Feb 2008 03:54:45 -0600	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

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 cpumask_t.
We end up with some big arrays of big cpumask_t's and nodemask_t's,
mostly filled with zero bits ... wasting memory.

I'll agree with Christoph on that, though I'd agree with you that this
bitmap relative operator is probably -not- the key to that more compact

The place that my thinking grinds to a halt on this is dealing with the
problem that all the more compact representations of a collection of
CPU numbers that I can think of either (1) are variable length (usually
leading to dynamic storage), or (2) impose some artificial restriction
on how many elements they can represent, or perhaps (3) use some
complex data structure to enumerate just the actual elements of the
power set of all cpus (or all nodes) that we actually use, which is
vastly less than the set of all possible subsets of such.

You address this artificial restriction yourself, in another message:
> I would rather just use arrays of integers in this case with a
> reasonable fixed upper limit (e.g. 16 or 32 -- if there are ever
> >32 thread x86 CPUs presumably they will require an updated cpufreq
> driver too...)

That might be the key here.  Perhaps as you suggest we can identify
some places where we can replace sparse cpumask_t's with (fixed length?)
arrays of integers, with little or no practical loss of generality, and
with nice reductions in memory footprint.

Mike Travis <> -- do you see some places where replacing
cpumask_t's with fixed arrays of 16 or 32 CPU numbers would be a big
enough win to be worth the effort?

                  I won't rest till it's the best ...
                  Programmer, Linux Scalability
                  Paul Jackson <> 1.940.382.4214

      parent reply	other threads:[~2008-02-15  9:54 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-02-14 12:35 Paul Jackson
2008-02-14 14:11 ` KOSAKI Motohiro
2008-02-14 16:35   ` Paul Jackson
2008-02-14 20:55     ` Ray Lee
2008-02-14 21:16       ` David Rientjes
2008-02-15 10:47         ` Paul Jackson
2008-02-15  0:24       ` KOSAKI Motohiro
2008-02-15 10:25         ` Paul Jackson
2008-02-15 10:58       ` Paul Jackson
2008-02-14 19:27 ` Christoph Lameter
2008-02-14 20:02   ` Andi Kleen
2008-02-14 20:06     ` Christoph Lameter
2008-02-14 20:25       ` Mike Travis
2008-02-14 20:30         ` Andi Kleen
2008-02-15  9:54     ` Paul Jackson [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \ \ \ \ \
    --subject='Re: [RFC] bitmap relative operator for mempolicy extensions' \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).