Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S966494Ab3E2Txo (ORCPT ); Wed, 29 May 2013 15:53:44 -0400 Received: from mail-qe0-f46.google.com ([209.85.128.46]:38464 "EHLO mail-qe0-f46.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1759631Ab3E2Txh (ORCPT ); Wed, 29 May 2013 15:53:37 -0400 Message-ID: <51A65CC0.3050800@gmail.com> Date: Wed, 29 May 2013 15:53:36 -0400 From: KOSAKI Motohiro User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Ingo Molnar CC: Christoph Lameter , Peter Zijlstra , Al Viro , Vince Weaver , linux-kernel@vger.kernel.org, Paul Mackerras , Ingo Molnar , Arnaldo Carvalho de Melo , trinity@vger.kernel.org, akpm@linux-foundation.org, torvalds@linux-foundation.org, roland@kernel.org, infinipath@qlogic.com, linux-mm@kvack.org, linux-rdma@vger.kernel.org, Or Gerlitz , Hugh Dickins , kosaki.motohiro@gmail.com Subject: [RFC][PATCH] mm: Fix RLIMIT_MEMLOCK References: <20130523104154.GA23650@twins.programming.kicks-ass.net> <0000013ed1b8d0cc-ad2bb878-51bd-430c-8159-629b23ed1b44-000000@email.amazonses.com> <20130523152458.GD23650@twins.programming.kicks-ass.net> <0000013ed2297ba8-467d474a-7068-45b3-9fa3-82641e6aa363-000000@email.amazonses.com> <20130523163901.GG23650@twins.programming.kicks-ass.net> <0000013ed28b638a-066d7dc7-b590-49f8-9423-badb9537b8b6-000000@email.amazonses.com> <20130524140114.GK23650@twins.programming.kicks-ass.net> <0000013ed732b615-748f574f-ccb8-4de7-bbe4-d85d1cbf0c9d-000000@email.amazonses.com> <20130527064834.GA2781@laptop> <0000013eec0006ee-0f8caf7b-cc94-4f54-ae38-0ca6623b7841-000000@email.amazonses.com> <20130529075845.GA24506@gmail.com> In-Reply-To: <20130529075845.GA24506@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1369 Lines: 26 Hi I'm unhappy you guys uses offensive word so much. Please cool down all you guys. :-/ In fact, _BOTH_ the behavior before and after Cristoph's patch doesn't have cleaner semantics. And PeterZ proposed make new cleaner one rather than revert. No need to hassle. I'm 100% sure -rt people need stronger-mlock api. Please join discussion to make better API. In my humble opinion is: we should make mlock3(addr, len flags) new syscall (*) and support -rt requirement directly. And current strange IB RLIMIT_MEMLOCK usage should gradually migrate it. (*) or, to enhance mbind() is an option because i expect apps need to pin pages nearby NUMA nodes in many case. As your know, current IB pinning implementation doesn't guarantee no minor fault when fork is used. It's ok for IB. They uses madvise(MADV_NOFORK) too. But I'm not sure *all* of rt application are satisfied this. We might need to implement copy-on-fork or might not. I'd like hear other people's opinion. Also, all developer should know this pinning breaks when memory hot-plug is happen likes cpu bounding bysched_setaffinity() may break when cpu hot-remove. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/