Re: + memory-hotplug-fix-kswapd-looping-forever-problem-fix-fix.patch added to -mm tree

[Minchan Kim <minchan@kernel.org>]

Hi Tejun,

On Wed, Jul 18, 2012 at 05:21:02PM -0700, Tejun Heo wrote:
> (cc'ing Yinghai, hi!)
> 
> Hello,
> 
> On Thu, Jul 19, 2012 at 09:10:02AM +0900, Minchan Kim wrote:
> > On Wed, Jul 18, 2012 at 02:38:10PM -0700, Andrew Morton wrote:
> > > On Wed, 18 Jul 2012 10:22:00 +0900
> > > Minchan Kim <minchan@kernel.org> wrote:
> > > 
> > > > > 
> > > > > Is this really necessary?  Does the zone start out all-zeroes?  If not, can we
> > > > > make it do so?
> > > > 
> > > > Good point.
> > > > It can remove zap_zone_vm_stats and zone->flags = 0, too.
> > > > More important thing is that we could remove adding code to initialize
> > > > zero whenever we add new field to zone. So I look at the code.
> > > > 
> > > > In summary, IMHO, all is already initialie zero out but we need double
> > > > check in mips.
> > > > 
> > > 
> > > Well, this is hardly a performance-critical path.  So rather than
> > > groveling around ensuring that each and every architectures does the
> > > right thing, would it not be better to put a single memset() into core
> > > MM if there is an appropriate place?
> > 
> > I think most good place is free_area_init_node but at a glance,
> > bootmem_data is set up eariler than free_area_init_node so shouldn't we
> > keep that pointer still?
> 
> I don't think zapping node_data that late is a good idea.  It's used

As I look over all arch code[1], they seem to zero out when pg_data_t is allocated.
So we might not need this but Andrew want to make sure it in core MM code.
[1] http://marc.info/?l=linux-mm&m=134257473810711&w=3

> from very early in the boot and its usage during early boot is fairly
> platform dependent.  Dunno whether there's a good solution for this.

You mean some arches might want to use pglist_data's any fields
freely during bootup? So free_area_init_node should initialize fields
for core MM part explicitly?
If so, do they want to use fields of pglist_dat->node_zones[ ] freely?
Maybe not. If they doesn't use them, we could zero out zone structure
at least, not pg_data_t and it could be helpful, too.

> Maybe trigger warning if some fields which have to be zero aren't?

It's not good because this causes adding new WARNING in that part
whenever we add new field in pgdat. It nullify this patch's goal.

> 
> Thanks.
> 
> -- 
> tejun
> 
> --
> To unsubscribe, send a message with 'unsubscribe linux-mm' in
> the body to majordomo@kvack.org.  For more info on Linux MM,
> see: http://www.linux-mm.org/ .
> Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

-- 
Kind regards,
Minchan Kim

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>