linux-kernel - Re: [RFC/PATCH] Make for_each_node

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:	Mon, 12 May 2008 09:45:15 -0700
From:	Mike Travis <travis@....com>
To:	Alexander van Heukelum <heukelum@...tmail.fm>
CC:	Paul Jackson <pj@....com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Ingo Molnar <mingo@...e.hu>,
	Thomas Gleixner <tglx@...utronix.de>,
	linux-arch@...r.kernel.org, linux-kernel@...r.kernel.org,
	Alexander van Heukelum <heukelum@...lshack.com>
Subject: Re: [RFC/PATCH] Make for_each_node_mask out-of-line

Alexander van Heukelum wrote:
> On Sun, 11 May 2008 16:01:04 -0500, "Paul Jackson" <pj@....com> said:
>> Alexander wrote:
>>> Sure. This patch introduces lib/nodemask.c, but I'm not quite sure
>>> if building it should depend on CONFIG_SMP or something else (NUMA?).
>>> When is MAX_NUMNODES 1?
>> Well ... I'm pretty sure it made sense to depend on SMP, back when
>> it was first added.  However that might have changed.  I recall
>> vaguely that there has been discussion of this CONFIG_SMP dependency
>> every year or so, but I don't have the time right now to dig through
>> the archives and code to figure it out.
>>
>> So ... offhand ... good questions, but I don't have answers.
>>
>>> I'ld be happy to take a stab at aligning the cpumask and nodemask
>>> code even more by uninlining some more functions and using stubs
>>> for the MAX_NUMNODES=1 case.
>> That could be good ... though could you co-ordinate with Mike Travis
>> first, to minimize the risks of merge conflicts with what he's doing?
> 
> I believe the x86#testing tree includes Mike's work? The two patches
> in this thread apply fine to current x86#testing.

Yes, my only change right now is to use nr_cpu_ids instead of NR_CPUS
which short cuts a huge chunk out of the back end of the loop.  And my
changes are in sched/latest (which includes x86/latest).

Thanks,
Mike

> 
>> You kernel text space saving in the first patch seemed worth going
>> ahead with even if it did conflict a little, and I liked the matching
>> nodemask patch, just to keep things in sync.  Other nodemask cleanup
>> is a little lower priority in my book, so should make a modest effort
>> to co-ordinate with more critical patches, to minimize conflict.
> 
> Thanks for your guidance.
> 
> Greetings,
>     Alexander
> 
>> -- 
>>                   I won't rest till it's the best ...
>>                   Programmer, Linux Scalability
>>                   Paul Jackson <pj@....com> 1.940.382.4214

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