[lkml]   [2006]   [Jan]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH] tvec_bases too large for per-cpu data
"Jan Beulich" <> 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
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2006-01-21 08:28    [W:0.091 / U:0.684 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site