Thread (13 messages) 13 messages, 3 authors, 2012-07-24

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

From: Minchan Kim <minchan@kernel.org>
Date: 2012-07-19 00:48:08

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:
quoted
On Wed, Jul 18, 2012 at 02:38:10PM -0700, Andrew Morton wrote:
quoted
On Wed, 18 Jul 2012 10:22:00 +0900
Minchan Kim [off-list ref] wrote:
quoted
quoted
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>
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help