On Fri, Jul 20, 2012 at 02:36:41PM -0700, Tejun Heo wrote: > Hello, Andrew. > > On Fri, Jul 20, 2012 at 02:22:13PM -0700, Andrew Morton wrote: > > My point is that having to ensure that each arch zeroes out this > > structure is difficult/costly/unreliable/fragile. It would be better > > if we can reliably clear it at some well-known place in core MM. > > > > That might mean that the memory gets cleared twice on some > > architectures, but I doubt if that matters - it's a once-off thing. > > Clearing twice isn't the problem here. The problem is the risk of > zapping fields which are already in use. That would be way more > unexpected and difficult to track down than garbage value in whatever > field. I would like to know what fields you are concerning because most of field in pg_data_t are generic except bdata so they would be initialized by free_area_init_node. So IMHO, reset pg_data_t except bdata would be no problem and clean approach. If some arch needs some fields in pg_data_t , we have to declare new variable struct arch_data in pg_data_t and generic functions doesn't need to touch them. Of course, we can skip reset of that structure, too. Please let me know it if I am missing something. -- Kind regards, Minchan Kim -- 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>