Re: [RFC:Patch: 000/008](memory hotplug) rough idea of pgdat removing

[Yasunori Goto]

> Yasunori Goto wrote:
> 
> > Current my idea is using RCU feature for waiting them.
> > Because it is the least impact against reader's performance,
> > and pgdat remover can wait finish of reader's access to pgdat
> > which is removing by synchronize_sched().
> 
> The use of RCU disables preemption which has implications as to
> what can be done in a loop over nodes or zones.

Yeap. It's the one of (big) cons.

> This would also potentially add more overhead to the page allocator hotpaths.

Agree.

To tell the truth, I tried hackbench with 3rd patch which add rcu_read_lock
in hot-path before this post to make rough estimate its impact.

%hackbench 100 process 2000

without patch.
  39.93

with patch
  39.99
(Both is 10 times avarage)

I guess this result has effect of disable preemption.
So, throughput looks not so bad, but probably, latency would be worse
as you mind.

Kame-san advised me I should take more other benchmarks which can get memory
performance. I'll do it next week.

> > If you have better idea, please let me know.
> 
> Use stop_machine()? The removal of a zone or node is a pretty rare event
> after all and it would avoid having to deal with rcu etc etc.
> 

I thought it at first, but are there the following worst case?


   CPU 0                                    CPU 1
-------------------------------------------------------
__alloc_pages()
    
    parsing_zonelist()
        :
    enter page_reclarim()
    sleep (and remember zone)                 :
                                              :
                                        update zonelist and node_online_map
                                          with stop_machine_run()
                                        free pgdat().
                                        remove the Node electrically.

    wake up and touch remembered
       zone,  but it is removed
    (Oops!!!)



Anyway, I'm happy if there is better way than my poor idea. :-)

Thanks for your comment.


-- 
Yasunori Goto 


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/