linux-kernel - Re: [git pull] cpus4096 fixes

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Sun, 27 Jul 2008 23:03:50 +0200
From:	Ingo Molnar <mingo@...e.hu>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Mike Travis <travis@....com>,
	Rusty Russell <rusty@...tcorp.com.au>
Subject: Re: [git pull] cpus4096 fixes

* Linus Torvalds <torvalds@...ux-foundation.org> wrote:

> On Sun, 27 Jul 2008, Ingo Molnar wrote:
> > 
> > Please pull the latest cpus4096-fixes git tree from:
> 
> No. Not without explanations.
> 
> Quite frankly, this "fix" looks like a huge stinking pile of sh*t.

Agreed :-/

NUMA-locality might have been a valid argument in favor of the massive 
array of constant cpumasks (common usage is to use it for the current 
cpu), if it wasnt all stupidly allocated on the boot node:

        cpumask_of_cpu_map = alloc_bootmem_low(sizeof(cpumask_t) * nr_cpu_ids);
        for (i = 0; i < nr_cpu_ids; i++)
                cpu_set(i, cpumask_of_cpu_map[i]);

> And I further right, and you are so STUPID that you cannot see that 
> you can share all the zero words?

That's fair to say :-/ I cannot talk for the others but it certainly 
didnt occur to me and i should have caught it.

( To me it didnt occur because we rarely have the opportunity for such 
  rather clever optimizations, in most cases there's really just two 
  choices in practice: either maximally global, or maximally per cpu. 
  Here we can do something inbetween and overlap. I dont think we do any 
  comparable compression of constants in the kernel. That boxed in my
  imagination i guess. )

Sorry about this - please ignore these patches, we'll rework them along 
the lines you suggest. Your suggested data structure will indeed be both 
simpler, smaller and more cache-efficient.

	Ingo
--
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/