linux-kernel - Re: sched: CPU #1's llc-sibling CPU #0 is not on the same 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]

Message-ID: <CAE9FiQV+FGmUwOgMJkcUkxdGgO_xgUEVQJ5eiLJPkjXa8XGRig@mail.gmail.com>
Date:	Wed, 27 Feb 2013 09:30:57 -0800
From:	Yinghai Lu <yinghai@...nel.org>
To:	"Luck, Tony" <tony.luck@...el.com>
Cc:	Yasuaki Ishimatsu <isimatu.yasuaki@...fujitsu.com>,
	Don Morris <don.morris@...com>,
	"H. Peter Anvin" <hpa@...or.com>, Tejun Heo <tj@...nel.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Thomas Renninger <trenn@...e.de>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Tim Gardner <tim.gardner@...onical.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"tglx@...utronix.de" <tglx@...utronix.de>,
	"mingo@...hat.com" <mingo@...hat.com>,
	"x86@...nel.org" <x86@...nel.org>,
	"a.p.zijlstra@...llo.nl" <a.p.zijlstra@...llo.nl>,
	"Sakkinen, Jarkko" <jarkko.sakkinen@...el.com>,
	"tangchen@...fujitsu.com" <tangchen@...fujitsu.com>
Subject: Re: sched: CPU #1's llc-sibling CPU #0 is not on the same node!

On Wed, Feb 27, 2013 at 8:28 AM, Luck, Tony <tony.luck@...el.com> wrote:
>> assume first cpu only have 1G ram, and other 31 socket will have bunch of ram
>
> That doesn't seem to be a very realistic assumption. Can you even still buy 1G
> DIMMs for servers?   I'd think that a minimum would be to have each of four
> channels populated with a 4G DIMM - so 16GB on first cpu. But even that feels
> rather low.

We could use memmap= to exclude mem, right?

>
> I think that making sure that the system can boot is good (and maybe it should
> ignore/override[*] parameters that would prevent booting). But let's be realistic
> about the cases we actually have to deal with (before somebody comes and talks
> about systems with just 16MB).

About make memory hotplug working:
1. find out ram that is used by kernel in early time.
2. check if
   a. it is with kernel code that will not be moved.
       like real_mode.
   b. it will be freed to slub before run time.
       like init code and initrd disk.
   c. if it is on local node ram that will not prevent mem hot-remove
       like page table and vmemmap.
       current we already have vmemmap and node_data on local node.
       May need to put page table on local node too. or just put page
       table with local node that kernel is on.
   d. something could be anywhere, and could be moved down after
       slub is ready.

movablemem_map patchset prevents kernel using kernel from local node.



In that case, so they should just boot system with numa=off.

Thanks

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