>>> Andrew Morton <[email protected]> 21.01.06 08:25:00 >>>
>"Jan Beulich" <[email protected]> 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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
