All of lore.kernel.org
 help / color / mirror / Atom feed
From: William Lee Irwin III <wli@holomorphy.com>
To: Keith Owens <kaos@ocs.com.au>
Cc: linux-kernel@vger.kernel.org
Subject: Re: cpu-2.5.64-1
Date: Sun, 16 Mar 2003 02:10:55 -0800	[thread overview]
Message-ID: <20030316101055.GG20188@holomorphy.com> (raw)
In-Reply-To: <16504.1047806371@ocs3.intra.ocs.com.au>

On Sun, 16 Mar 2003 00:36:09 -0800, William Lee Irwin III wrote:
>> That was a bit too braindead of a translation, yes. But it is x86 arch
>> code so it shouldn't be that large of an issue for big MIPS boxen etc.
>> I'll search & replace for stuff of this kind and wipe it out anyway.

On Sun, Mar 16, 2003 at 08:19:31PM +1100, Keith Owens wrote:
> Good, it lets us optimize for 1/32/64/lots of cpus.  NR_CPUS > 8 *
> sizeof(unsigned long) is the interesting case, it needs arrays.

Hmm. It shouldn't make a difference with respect to optimizing them.
My API passes transparently by reference:

#include <linux/bitmap.h>

#define CPU_ARRAY_SIZE         BITS_TO_LONGS(NR_CPUS)

struct cpumask
{
       unsigned long mask[CPU_ARRAY_SIZE];
};

typedef struct cpumask cpumask_t;

#define cpu_set(cpu, map)		set_bit(cpu, (map).mask)
#define cpu_clear(cpu, map)		clear_bit(cpu, (map).mask)
#define cpu_isset(cpu, map)		test_bit(cpu, (map).mask)
#define cpu_test_and_set(cpu, map)	test_and_set_bit(cpu, (map).mask)
+
#define cpus_and(dst,src1,src2)		bitmap_and((dst).mask, (src1).mask, (src2).mask, NR_CPUS)
#define cpus_or(dst,src1,src2)		bitmap_or((dst).mask, (src1).mask, (src2).mask, NR_CPUS)
#define cpus_clear(map)			bitmap_clear((map).mask, NR_CPUS)
#define cpus_equal(map1, map2)		bitmap_equal((map1).mask, (map2).mask, NR_CPUS)
#define cpus_empty(map)			(any_online_cpu(map) >= NR_CPUS)
#define first_cpu(map)			find_first_bit((map).mask, NR_CPUS)
#define next_cpu(cpu, map)		find_next_bit((map).mask, NR_CPUS, cpu)


i.e. the structures vaguely look like they're being passed by value and
I get the pointer to the start of the array with implicit decay.

Now the special case exploits the appearance of call by value:

#else /* !CONFIG_SMP */

typedef unsigned long cpumask_t;

#define any_online_cpu(map)		((map) != 0UL)
#define cpu_set(cpu, map)		do { map |= 1UL << (cpu); } while (0)
#define cpu_clear(cpu, map)		do { map &= ~(1UL << (cpu)); } while (0)
#define cpu_isset(cpu, map)		((map) & (1UL << (cpu)))
#define cpu_test_and_set(cpu, map)	test_and_set_bit(cpu, &(map))
#define cpus_and(dst,src1,src2)		do { dst = (src1) & (src2); } while (0)
#define cpus_or(dst,src1,src2)		do { dst = (src1) | (src2); } while (0)
#define cpus_clear(map)			do { map = 0UL; } while (0)
#define cpus_equal(map1, map2)		((map1) == (map2))
#define cpus_empty(map)			((map) != 0UL)
#define first_cpu(map)			0
#define next_cpu(cpu, map)		NR_CPUS

... okay, a couple of minor fixups are needed for small-scale SMP, but
you get the idea. So basically the references to cpu_online_map don't
affect the UP/tinySMP special-casing b/c of the calling conventions
giving enough play to use either pointers (wrapped in structures) or
plain old unsigned longs.

fixups:

#define first_cpu(map)			__ffs(map)
#define next_cpu(cpu, map)		__ffs((map) & ~((1UL < (cpu)) - 1))

*and* the plain old bugfix(!):

#define cpus_empty(map)			((map) == 0UL)


So mostly there isn't much to get excited about, but using
cpu_online_map directly doesn't appear to be a plus or a minus for my
strategy, if it in fact differs enough from any of the various others
of these posted before to be able to be called my own.


-- wli

  parent reply	other threads:[~2003-03-16 10:00 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-03-11  4:24 cpu-2.5.64-1 William Lee Irwin III
2003-03-11  7:17 ` cpu-2.5.64-1 Zwane Mwaikambo
2003-03-11  8:25   ` cpu-2.5.64-1 Zwane Mwaikambo
2003-03-16  7:39 ` cpu-2.5.64-1 Keith Owens
2003-03-16  8:36   ` cpu-2.5.64-1 William Lee Irwin III
2003-03-16  9:19     ` cpu-2.5.64-1 Keith Owens
2003-03-16  9:46       ` cpu-2.5.64-1 William Lee Irwin III
2003-03-16 10:10       ` William Lee Irwin III [this message]
2003-03-16 11:12         ` cpu-2.5.64-1 Keith Owens
2003-03-16 11:32           ` cpu-2.5.64-1 William Lee Irwin III
2003-03-16 11:53             ` cpu-2.5.64-1 Keith Owens
2003-03-16 12:00               ` cpu-2.5.64-1 William Lee Irwin III
2003-03-16 12:42             ` cpu-2.5.64-1 Horst von Brand
2003-03-16 19:14               ` cpu-2.5.64-1 William Lee Irwin III

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:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

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

  git send-email \
    --in-reply-to=20030316101055.GG20188@holomorphy.com \
    --to=wli@holomorphy.com \
    --cc=kaos@ocs.com.au \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.