Messages in this thread | | | Date | Fri, 20 Jan 2006 23:25:00 -0800 | From | Andrew Morton <> | Subject | Re: [PATCH] tvec_bases too large for per-cpu data |
| |
"Jan Beulich" <JBeulich@novell.com> wrote: > > The biggest arch-independent consumer is tvec_bases (over 4k on 32-bit > archs, > over 8k on 64-bit ones), which now gets converted to use dynamically > allocated > memory instead.
ho hum, another pointer hop.
Did you consider using alloc_percpu()?
The patch does trickery in init_timers_cpu() which, from my reading, defers the actual per-cpu allocation until the second CPU comes online. Presumably because of some ordering issue which you discovered. Readers of the code need to know what that issue was.
And boot_tvec_bases will always be used for the BP, and hence one slot in the per-cpu array will forever be unused. Until the BP is taken down and brought back up, in which case it will suddenly start to use a dynamically allocated structure.
But all of this modification was unchangelogged and is uncommented, so I'm somewhat guessing here. Please always ensure that tricksy things like this have complete covering comments.
Also, the new code would appear to leak one tvec_base_t per cpu-unplugging? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |