From: Ingo Molnar <mingo-X9Un+BFzKDI@public.gmane.org> To: Yinghai Lu <yinghai-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> Cc: steiner-sJ/iWh9BUns@public.gmane.org, cl-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org, suresh.b.siddha-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org, mel-wPRd99KPJ+uzQB+pC5nmwQ@public.gmane.org, containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org, rusty-8n+1lVoiYb80n/F98K4Iww@public.gmane.org, linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, ntl-e+AXbWqSrlAAvxtiuMwx3w@public.gmane.org, viro-RmSDqhL/yNMiFSDQTTA3OLVCufUGDwFn@public.gmane.org, hpa-YMNOUZJC4hwAvxtiuMwx3w@public.gmane.org, rientjes-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org, Andrew Morton <akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org>, tglx-hfZtesqFncYOwBW4kG4KsQ@public.gmane.org Subject: Re: [PATCH] x86: only clear node_states for 64bit Date: Sat, 27 Jun 2009 19:17:14 +0200 [thread overview] Message-ID: <20090627171714.GD21595@elte.hu> (raw) In-Reply-To: <4A4538FE.2090101-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> * Yinghai Lu <yinghai-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> wrote: > Andrew Morton wrote: > > On Mon, 22 Jun 2009 08:38:50 -0700 > > Yinghai Lu <yinghai-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> wrote: > > > >> Nathan reported that > >> | commit 73d60b7f747176dbdff826c4127d22e1fd3f9f74 > >> | Author: Yinghai Lu <yinghai-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> > >> | Date: Tue Jun 16 15:33:00 2009 -0700 > >> | > >> | page-allocator: clear N_HIGH_MEMORY map before we set it again > >> | > >> | SRAT tables may contains nodes of very small size. The arch code may > >> | decide to not activate such a node. However, currently the early boot > >> | code sets N_HIGH_MEMORY for such nodes. These nodes therefore seem to be > >> | active although these nodes have no present pages. > >> | > >> | For 64bit N_HIGH_MEMORY == N_NORMAL_MEMORY, so that works for 64 bit too > >> > >> the cpuset.mems cgroup attribute on an i386 kvm guest > >> > >> fix it by only clearing node_states[N_NORMAL_MEMORY] for 64bit only. > >> and need to do save/restore for that in find_zone_movable_pfn > >> > > > > There appear to be some words omitted from this changelog - it doesn't > > make sense. > > > > I think that perhaps a line got deleted before "the cpuset.mems cgroup > > ...". That was the line which actualy describes the bug which we're > > fixing. Or perhaps it was a single word? "zeroes". > > > > > > I did this: > > > > Nathan reported that > > : > > : | commit 73d60b7f747176dbdff826c4127d22e1fd3f9f74 > > : | Author: Yinghai Lu <yinghai-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> > > : | Date: Tue Jun 16 15:33:00 2009 -0700 > > : | > > : | page-allocator: clear N_HIGH_MEMORY map before we set it again > > : | > > : | SRAT tables may contains nodes of very small size. The arch code may > > : | decide to not activate such a node. However, currently the early boot > > : | code sets N_HIGH_MEMORY for such nodes. These nodes therefore seem to be > > : | active although these nodes have no present pages. > > : | > > : | For 64bit N_HIGH_MEMORY == N_NORMAL_MEMORY, so that works for 64 bit too > > : > > " > > : unintentionally and incorrectly clears the cpuset.mems cgroup attribute on > > : an i386 kvm guest > " > ==> > > 32bit assume NORMAL_MEMORY bit and HIGH_MEMORY bit are set for > Node0 always. Where in the code is this assumption? > and some code only check if HIGH_MEMORY is there to know if > NORMAL_MEMORY is there. Which code is that exactly? Ingo
WARNING: multiple messages have this Message-ID (diff)
From: Ingo Molnar <mingo@elte.hu> To: Yinghai Lu <yinghai@kernel.org> Cc: Andrew Morton <akpm@linux-foundation.org>, cl@linux-foundation.org, tglx@linutronix.de, hpa@zytor.com, ntl@pobox.com, mel@csn.ul.ie, suresh.b.siddha@intel.com, linux-kernel@vger.kernel.org, viro@zeniv.linux.org.uk, rusty@rustcorp.com.au, steiner@sgi.com, rientjes@google.com, containers@lists.linux-foundation.org Subject: Re: [PATCH] x86: only clear node_states for 64bit Date: Sat, 27 Jun 2009 19:17:14 +0200 [thread overview] Message-ID: <20090627171714.GD21595@elte.hu> (raw) In-Reply-To: <4A4538FE.2090101@kernel.org> * Yinghai Lu <yinghai@kernel.org> wrote: > Andrew Morton wrote: > > On Mon, 22 Jun 2009 08:38:50 -0700 > > Yinghai Lu <yinghai@kernel.org> wrote: > > > >> Nathan reported that > >> | commit 73d60b7f747176dbdff826c4127d22e1fd3f9f74 > >> | Author: Yinghai Lu <yinghai@kernel.org> > >> | Date: Tue Jun 16 15:33:00 2009 -0700 > >> | > >> | page-allocator: clear N_HIGH_MEMORY map before we set it again > >> | > >> | SRAT tables may contains nodes of very small size. The arch code may > >> | decide to not activate such a node. However, currently the early boot > >> | code sets N_HIGH_MEMORY for such nodes. These nodes therefore seem to be > >> | active although these nodes have no present pages. > >> | > >> | For 64bit N_HIGH_MEMORY == N_NORMAL_MEMORY, so that works for 64 bit too > >> > >> the cpuset.mems cgroup attribute on an i386 kvm guest > >> > >> fix it by only clearing node_states[N_NORMAL_MEMORY] for 64bit only. > >> and need to do save/restore for that in find_zone_movable_pfn > >> > > > > There appear to be some words omitted from this changelog - it doesn't > > make sense. > > > > I think that perhaps a line got deleted before "the cpuset.mems cgroup > > ...". That was the line which actualy describes the bug which we're > > fixing. Or perhaps it was a single word? "zeroes". > > > > > > I did this: > > > > Nathan reported that > > : > > : | commit 73d60b7f747176dbdff826c4127d22e1fd3f9f74 > > : | Author: Yinghai Lu <yinghai@kernel.org> > > : | Date: Tue Jun 16 15:33:00 2009 -0700 > > : | > > : | page-allocator: clear N_HIGH_MEMORY map before we set it again > > : | > > : | SRAT tables may contains nodes of very small size. The arch code may > > : | decide to not activate such a node. However, currently the early boot > > : | code sets N_HIGH_MEMORY for such nodes. These nodes therefore seem to be > > : | active although these nodes have no present pages. > > : | > > : | For 64bit N_HIGH_MEMORY == N_NORMAL_MEMORY, so that works for 64 bit too > > : > > " > > : unintentionally and incorrectly clears the cpuset.mems cgroup attribute on > > : an i386 kvm guest > " > ==> > > 32bit assume NORMAL_MEMORY bit and HIGH_MEMORY bit are set for > Node0 always. Where in the code is this assumption? > and some code only check if HIGH_MEMORY is there to know if > NORMAL_MEMORY is there. Which code is that exactly? Ingo
next prev parent reply other threads:[~2009-06-27 17:17 UTC|newest] Thread overview: 102+ messages / expand[flat|nested] mbox.gz Atom feed top 2009-05-09 6:45 [PATCH 1/3] x86: remove MEMORY_HOTPLUG_RESERVE related code Yinghai Lu 2009-05-09 6:48 ` [PATCH 2/3] x86: add numa_move_cpus_to_node Yinghai Lu 2009-05-09 7:05 ` Justin P. Mattock 2009-05-12 1:27 ` Christoph Lameter 2009-05-11 21:53 ` Yinghai Lu 2009-05-12 20:59 ` Christoph Lameter 2009-05-12 17:16 ` Yinghai Lu 2009-05-12 21:21 ` Christoph Lameter 2009-05-13 5:39 ` Yinghai Lu 2009-05-14 19:34 ` Christoph Lameter 2009-05-14 20:58 ` Yinghai Lu 2009-05-09 6:50 ` [PATCH 3/3] x86: fix node_possible_map logic -v2 Yinghai Lu 2009-05-11 17:53 ` Jack Steiner 2009-05-11 19:15 ` Yinghai Lu 2009-05-11 19:36 ` Yinghai Lu 2009-05-11 19:27 ` David Rientjes 2009-05-11 21:12 ` H. Peter Anvin 2009-05-11 21:26 ` Alan Cox 2009-05-11 22:25 ` David Rientjes 2009-05-12 15:06 ` Jack Steiner 2009-05-12 15:10 ` Yinghai Lu 2009-05-12 16:16 ` Jack Steiner 2009-05-12 16:40 ` Yinghai Lu 2009-05-12 18:03 ` Jack Steiner 2009-05-12 21:31 ` Yinghai Lu 2009-05-12 21:58 ` Jack Steiner 2009-05-12 23:13 ` Yinghai Lu 2009-05-12 23:26 ` Yinghai Lu 2009-05-12 15:43 ` Andi Kleen 2009-05-13 1:34 ` [PATCH] x86: fix system without memory on node0 Yinghai Lu 2009-05-13 8:00 ` Andi Kleen 2009-05-13 15:58 ` Yinghai Lu 2009-05-13 13:35 ` Ingo Molnar 2009-05-13 16:52 ` Jack Steiner 2009-05-13 17:43 ` Yinghai Lu 2009-05-13 18:08 ` Yinghai Lu 2009-05-12 7:15 ` [PATCH 3/3] x86: fix node_possible_map logic -v2 Andi Kleen 2009-05-11 21:33 ` Jack Steiner 2009-05-11 22:56 ` David Rientjes 2009-05-11 23:00 ` Yinghai Lu 2009-05-12 7:09 ` Andi Kleen 2009-05-12 1:02 ` [PATCH 1/3] x86: remove MEMORY_HOTPLUG_RESERVE related code Christoph Lameter 2009-05-12 11:16 ` Mel Gorman 2009-05-13 5:29 ` Yinghai Lu 2009-05-13 9:55 ` Mel Gorman 2009-05-13 6:13 ` [PATCH] x86: remove MEMORY_HOTPLUG_RESERVE related code -v2 Yinghai Lu 2009-05-13 14:59 ` Mel Gorman 2009-05-14 16:38 ` [PATCH 1/5] " Yinghai Lu 2009-05-14 16:40 ` [PATCH 2/5] x86: add numa_move_cpus_to_node Yinghai Lu 2009-05-14 16:41 ` [PATCH 3/5] x86: fix node_possible_map logic -v2 Yinghai Lu 2009-05-18 7:40 ` [tip:x86/mm] x86, mm: Fix node_possible_map logic tip-bot for Yinghai Lu 2009-05-14 16:42 ` [PATCH 4/5] x86: fix system without memory on node0 -v2 Yinghai Lu 2009-05-18 7:40 ` [tip:x86/mm] x86: fix system without memory on node0 tip-bot for Yinghai Lu 2009-05-14 16:43 ` [PATCH 5/5] mm: clear N_HIGH_MEMORY map before se set it again -v2 Yinghai Lu 2009-05-14 16:54 ` Andrew Morton 2009-05-14 17:05 ` Yinghai Lu 2009-05-14 17:25 ` Andrew Morton 2009-05-14 17:34 ` Yinghai Lu 2009-05-14 19:44 ` Christoph Lameter 2009-06-04 5:16 ` [RESEND PATCH] " Yinghai Lu 2009-06-04 16:38 ` Christoph Lameter 2009-06-04 16:48 ` Yinghai Lu 2009-06-04 17:11 ` Christoph Lameter 2009-06-04 17:26 ` [PATCH] mm: clear N_HIGH_MEMORY map before se set it again -v4 Yinghai Lu 2009-06-19 6:42 ` Nathan Lynch 2009-06-19 8:18 ` Yinghai Lu [not found] ` <4A3B49BA.40100-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> 2009-06-19 8:43 ` Nathan Lynch 2009-06-19 8:43 ` Nathan Lynch 2009-06-19 16:16 ` Yinghai Lu [not found] ` <m3prd0havh.fsf-e+AXbWqSrlAAvxtiuMwx3w@public.gmane.org> 2009-06-19 16:16 ` Yinghai Lu 2009-06-20 23:43 ` Yinghai Lu 2009-06-20 23:43 ` Yinghai Lu [not found] ` <4A3D7419.8040305-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> 2009-06-22 4:39 ` Nathan Lynch 2009-06-22 4:39 ` Nathan Lynch 2009-06-22 15:38 ` [PATCH] x86: only clear node_states for 64bit Yinghai Lu [not found] ` <4A3FA58A.3010909-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> 2009-06-26 20:54 ` Andrew Morton 2009-06-26 20:54 ` Andrew Morton 2009-06-26 21:09 ` Yinghai Lu [not found] ` <4A4538FE.2090101-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> 2009-06-27 17:17 ` Ingo Molnar [this message] 2009-06-27 17:17 ` Ingo Molnar [not found] ` <20090627171714.GD21595-X9Un+BFzKDI@public.gmane.org> 2009-06-27 20:40 ` Yinghai Lu 2009-06-27 20:40 ` Yinghai Lu [not found] ` <4A4683B2.106-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> 2009-06-29 7:39 ` Yinghai Lu 2009-06-29 7:39 ` Yinghai Lu [not found] ` <20090626135428.d8f88a70.akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org> 2009-06-26 21:09 ` Yinghai Lu [not found] ` <m3my807ug3.fsf-e+AXbWqSrlAAvxtiuMwx3w@public.gmane.org> 2009-06-22 15:38 ` Yinghai Lu [not found] ` <m3bpokiv0u.fsf-e+AXbWqSrlAAvxtiuMwx3w@public.gmane.org> 2009-06-19 8:18 ` [PATCH] mm: clear N_HIGH_MEMORY map before se set it again -v4 Yinghai Lu [not found] ` <4A2803D1.4070001-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> 2009-06-19 6:42 ` Nathan Lynch 2009-05-18 7:39 ` [tip:x86/mm] mm, x86: remove MEMORY_HOTPLUG_RESERVE related code tip-bot for Yinghai Lu [not found] ` <20090511095022.GA23121@elte.hu> [not found] ` <20090511163158.c4e4d334.akpm@linux-foundation.org> [not found] ` <20090512090704.GC18004@elte.hu> [not found] ` <4A0A6700.3070100@kernel.org> [not found] ` <20090513133635.GB7384@elte.hu> [not found] ` <4A0AFA6E.5050200@kernel.org> [not found] ` <20090515173521.GA29647@elte.hu> 2009-05-15 21:38 ` tip: patches in git for irq and numa Yinghai Lu 2009-05-18 7:29 ` Ingo Molnar 2009-05-18 13:50 ` Peter Zijlstra 2009-05-18 13:56 ` Ingo Molnar 2009-05-18 15:03 ` Yinghai Lu 2009-05-18 15:09 ` Ingo Molnar 2009-05-18 15:11 ` Peter Zijlstra 2009-05-18 17:23 ` Yinghai Lu 2009-05-19 9:37 ` Ingo Molnar 2009-05-19 10:31 ` Peter Zijlstra 2009-05-19 12:26 ` Ingo Molnar 2009-05-19 9:39 ` [tip:irq/numa] x86, io-apic: Don't mark pin_programmed early tip-bot for Yinghai Lu 2009-05-19 12:30 ` tip-bot for Yinghai Lu
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=20090627171714.GD21595@elte.hu \ --to=mingo-x9un+bfzkdi@public.gmane.org \ --cc=akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org \ --cc=cl-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org \ --cc=containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org \ --cc=hpa-YMNOUZJC4hwAvxtiuMwx3w@public.gmane.org \ --cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \ --cc=mel-wPRd99KPJ+uzQB+pC5nmwQ@public.gmane.org \ --cc=ntl-e+AXbWqSrlAAvxtiuMwx3w@public.gmane.org \ --cc=rientjes-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org \ --cc=rusty-8n+1lVoiYb80n/F98K4Iww@public.gmane.org \ --cc=steiner-sJ/iWh9BUns@public.gmane.org \ --cc=suresh.b.siddha-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org \ --cc=tglx-hfZtesqFncYOwBW4kG4KsQ@public.gmane.org \ --cc=viro-RmSDqhL/yNMiFSDQTTA3OLVCufUGDwFn@public.gmane.org \ --cc=yinghai-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.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: linkBe 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.