[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <201007121732.26092.rusty@rustcorp.com.au>
Date: Mon, 12 Jul 2010 17:32:24 +0930
From: Rusty Russell <rusty@...tcorp.com.au>
To: Eric Dumazet <eric.dumazet@...il.com>
Cc: Linus Torvalds <torvalds@...ux-foundation.org>,
Steven Rostedt <rostedt@...dmis.org>,
Tejun Heo <tj@...nel.org>, Ingo Molnar <mingo@...e.hu>,
Thomas Gleixner <tglx@...utronix.de>,
"H. Peter Anvin" <hpa@...or.com>,
Peter Zijlstra <peterz@...radead.org>,
"the arch/x86 maintainers" <x86@...nel.org>,
lkml <linux-kernel@...r.kernel.org>,
Christoph Lameter <cl@...ux-foundation.org>,
Frederic Weisbecker <fweisbec@...il.com>
Subject: Re: [RFC PATCH] x86-64: software IRQ masking and handling
On Mon, 12 Jul 2010 02:41:33 pm Eric Dumazet wrote:
> Two changes are possible :
>
> 1) Get rid of the cpu_online_mask (its a const pointer to a known
> target). I cant see a reason for its need it actually...
There was a reason, but I'm trying to remember it.
ISTR, it was to catch direct frobbing of the masks. That was important:
we were converting code everywhere to hand around cpumasks by ptr
rather than by copy. But that semantic change meant that a function which
previously harmlessly frobbed a copy would now frob (say) cpu_online_mask.
However, ((const struct cpumask *)cpu_online_bits)) would work for that
too. (Well, renaming cpu_online_bits to __cpu_online_bits would be better
since it's not non-static).
Ideally, those masks too would be dynamically allocated. But the boot
changes required for that are best left until someone really needs > 64k
CPUs.
> 2) Dont use a the last const qualifier but __read_mostly to move
> cpu_online_mask on same section.
>
> Rusty, could you comment on one or other way before I submit a patch ?
>
> (Of course, possible/present/active have same problem)
Yep. Might want to do a patch to get rid of the remaining 100 references
to cpu_online_map (etc) as well if you're feeling enthusiastic :)
Thanks!
Rusty.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists