From mboxrd@z Thu Jan 1 00:00:00 1970 From: Roland Dreier Subject: Re: [RFC] libibverbs: ibv_fork_init() and libhugetlbfs Date: Wed, 12 May 2010 09:40:16 -0700 Message-ID: References: <20100506093949.55916ab0@alex-laptop> <20100507121936.283a18c6@alex-laptop> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: In-Reply-To: <20100507121936.283a18c6@alex-laptop> (Alexander Schmidt's message of "Fri, 7 May 2010 12:19:36 +0200") Sender: linux-rdma-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: Alexander Schmidt Cc: of-ewg , Linux RDMA , Hoang-Nam Nguyen , Stefan Roscher , Joachim Fenkes , Christoph Raisch , Alex Vainman List-Id: linux-rdma@vger.kernel.org > * added get_huge_page_size() to read the huge page size from > /proc/meminfo. This is done at ibv_fork_init() time. That doesn't work on systems that have multiple huge page sizes (eg powerpc). You can compare the code to get the size in libhugetlbfs. Also I think the munging through /proc/pid/maps doesn't really work. First of all, essentially grepping for libhugetlbfs is not robust as I mentioned -- this will break in the same way for apps using huge pages directly. And while it is nice to be able to tell if a range came from libhugetlbfs, I think there may be some bad performance impact from reading /proc/pid/maps line-by-line. (And by the way, as a trivial optimization, it would make sense to me to check the address of each map before doing the strstr). - R. -- Roland Dreier || For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html