>> The BIOS always sends CPU hot-addition events before memory >> hot-addition events, so it's hard to change the order. >> And we couldn't completely solve this performance penalty because the >> affected code tries to allocate memory for all possible >> CPUs instead of onlined CPUs. > > So the BIOS is fucked, news at 11, one would have hoped Intel would have > _some_ say in it, but alas. So how about instead you force memory online > when you online the first CPU, screw whatever the BIOS does or does not?
Certainly an interesting implementation choice by the BIOS. The only logical order to use to bring components of a modern cpu online is: 1) Memory - so we have a place to allocate structure needed for following steps 2) Cores - so we have a place to direct interrupts from next step 3) I/O We should log a bug against the BIOS ... but systems are already shipping so we will have to deal with this. Either we use your existing patch - and systems with silly BIOS will work, but with a small NUMA penalty for objects allocated remotely or ... we implement some crazy queuing scheme ... where we delay bringing cores online for a while to see whether more things like memory and I/O start showing up too. We can't wait forever - people sometimes do configure systems with memory-less nodes. I think your existing solution is the better choice ... the penalties probably aren't all that big ... so extensive workarounds for BIOS bugs seem like the wrong direction. Maybe a one-time printk() so the user knows they have a buggy BIOS might help provide back pressure to BIOS teams to do this right in the future? But it isn't a bug for the memory-less node case. -Tony -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
