Re: [PATCH 2/6] change alloc function in pcpu_alloc_pages

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi, Christoph. 

On Fri, 2010-04-16 at 11:07 -0500, Christoph Lameter wrote:
> On Thu, 15 Apr 2010, Minchan Kim wrote:
> 
> > I don't want to remove alloc_pages for UMA system.
> 
> alloc_pages is the same as alloc_pages_any_node so why have it?

I don't want to force using '_node' postfix on UMA users.
Maybe they don't care getting page from any node and event don't need to
know about _NODE_. 

> 
> > #define alloc_pages alloc_page_sexact_node
> >
> > What I want to remove is just alloc_pages_node. :)
> 
> Why remove it? If you want to get rid of -1 handling then check all the

alloc_pages_node have multiple meaning as you said. So some of users
misuses that API. I want to clear intention of user.

> callsites and make sure that they are not using  -1.

Sure. I must do it before any progressing. 

> 
> Also could you define a constant for -1? -1 may have various meanings. One
> is the local node and the other is any node. The difference is if memory
> policies are obeyed or not. Note that alloc_pages follows memory policies
> whereas alloc_pages_node does not.
> 
> Therefore
> 
> alloc_pages() != alloc_pages_node(  , -1)
> 

Yes, now it's totally different. 
On UMA, It's any node but on NUMA, local node.

My concern is following as. 

alloc_pages_node means any node but it has nid argument. 
Why should user of alloc_pages who want to get page from any node pass
nid argument? It's rather awkward. 

Some of user misunderstood it and used alloc_pages_node instead of
alloc_pages_exact_node although he already know exact _NID_. 
Of course, it's not a BUG since if nid >= 0 it works well.

But I want to remove such multiple meaning to clear intention of user. 



-- 
Kind regards,
Minchan Kim


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

[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]