Re: [PATCH] tvec_bases too large for per-cpu data

[Jan Beulich]

>>> Andrew Morton <akpm@xxxxxxxx> 21.01.06 08:25:00 >>>
>"Jan Beulich" <JBeulich@xxxxxxxxxx> 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()?

I did, but I saw drawbacks with that (most notably the fact that all instances are allocated at
once, possibly wasting a lot of memory).

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

No, I don't see any trickery there (on demand allocation in CPU_UP_PREPARE is being done
elsewhere in very similar ways), and I also didn't see any ordering issues. Hence I also didn't
see any need to explain this in detail.

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

Why? Each slot is allocated at most once, the BP's is never allocated (it will continue to use the
static one even when brought down and back up).

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

Not really, as it would be re-used the next time a cpu with the same ID gets brought up (that
is, compared with the current situation there is generally less memory wasted unless all NR_CPUs
are brought up and then one or more down again, in which case the amount of space wasted
would equal [neglecting the slack space resulting from kmalloc's way of allocating]).

Jan
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/