On Thu 14-12-17 16:55:54, kemi wrote: > > > On 2017年12月14日 15:29, Michal Hocko wrote: > > On Thu 14-12-17 09:40:32, kemi wrote: > >> > >> > >> or sometimes > >> NUMA stats can't be disabled in their environments. > > > > why? > > > >> That's the reason > >> why we spent time to do that optimization other than simply adding a runtime > >> configuration interface. > >> > >> Furthermore, the code we optimized for is the core area of kernel that can > >> benefit most of kernel actions, more or less I think. > >> > >> All right, let's think about it in another way, does a u64 percpu array per-node > >> for NUMA stats really make code too much complicated and hard to maintain? > >> I'm afraid not IMHO. > > > > I disagree. The whole numa stat things has turned out to be nasty to > > maintain. For a very limited gain. Now you are just shifting that > > elsewhere. Look, there are other counters taken in the allocator, we do > > not want to treat them specially. We have a nice per-cpu infrastructure > > here so I really fail to see why we should code-around it. If that can > > be improved then by all means let's do it. > > > > Yes, I agree with you that we may improve current per-cpu infrastructure. > May we have a chance to increase the size of vm_node_stat_diff from s8 to s16 for > this "per-cpu infrastructure" (s32 in per-cpu counter infrastructure)? The > limitation of type s8 seems not enough with more and more cpu cores, especially > for those monotone increasing type of counters like NUMA counters. > > before after(moving numa to per_cpu_nodestat > and change s8 to s16) > sizeof(struct per_cpu_nodestat) 28 68 > > If ok, we can also keep that improvement in a nice way. I wouldn't be opposed. Maybe we should make it nr_cpus sized. -- Michal Hocko SUSE Labs -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>
