From patchwork Fri Sep 18 10:27:34 2015 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Balazs Kezes X-Patchwork-Id: 519230 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id B1E36140271 for ; Fri, 18 Sep 2015 20:27:26 +1000 (AEST) Authentication-Results: ozlabs.org; dkim=pass (1024-bit key; secure) header.d=sourceware.org header.i=@sourceware.org header.b=at97anJw; dkim-atps=neutral DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:date:from:to:subject:message-id:mime-version :content-type; q=dns; s=default; b=ZLELIpGruHoOTTw9INs+jws/KbMl5 y/ZebVpQYO61QWL1vkZwFLYiE2D1csLCz9EU0seni9WDUhiRSllav6XVTTFXMfaZ Ne4zPLdtmHo26y8dhoDCl1D9Sab+awDpwbv8cJDO2mDbYH7ZKBbKe10Pq4Z0Oeho DA3DC681ZlynuI= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:date:from:to:subject:message-id:mime-version :content-type; s=default; bh=+Lg4iR5Gp0nTbYjXSa2YUZWPnr8=; b=at9 7anJw7c9/6CZOdcF88KDrV3/rY/yW240pO7IL+0HhwvVr/da/iQuyq1Es9Yyy6Er Gjx8ESOnlbdc3NuzpeXaRyXYNNvxnX5sAWt+Ua7fD1OHP2U6E7s57w/24RUQZkQE ca4lTFH/wUWdKnmCJzbKVa/QghbE4V6+6rwWe2/A= Received: (qmail 29757 invoked by alias); 18 Sep 2015 10:27:20 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Delivered-To: mailing list libc-alpha@sourceware.org Received: (qmail 29747 invoked by uid 89); 18 Sep 2015 10:27:19 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.6 required=5.0 tests=BAYES_00, FREEMAIL_FROM, RCVD_IN_DNSWL_LOW, SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-wi0-f171.google.com X-Received: by 10.180.230.197 with SMTP id ta5mr36746998wic.26.1442572035378; Fri, 18 Sep 2015 03:27:15 -0700 (PDT) Date: Fri, 18 Sep 2015 11:27:34 +0100 From: Balazs Kezes To: libc-alpha@sourceware.org Subject: pthread wastes memory with mlockall(MCL_FUTURE) Message-ID: <20150918102734.GA27881@eper> MIME-Version: 1.0 Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Hi! I've run into the following problem: Whenever a new thread is created, pthread creates some guard pages next to its stack. These guard pages are usually empty zero pages, and have all their permissions removed -- nothing can read/write/execute on these pages. The problem is that the application I use has a large number of threads and uses mlockall(MCL_FUTURE) so this messes up the memory usage calculation (rss) for the application which then leads to memory wasted. Would it make sense for glibc to munlock these pages? I'm thinking something like this (although I haven't tested it yet): Thanks! diff --git a/nptl/allocatestack.c b/nptl/allocatestack.c index 753da61..1fc715c 100644 --- a/nptl/allocatestack.c +++ b/nptl/allocatestack.c @@ -659,6 +659,11 @@ allocate_stack (const struct pthread_attr *attr, struct pthread **pdp, return errno; } + /* The guard pages shouldn't be locked into memory. A lot of memory + would be unnecessarily wasted if you have a lot of threads and + mlockall(MCL_FUTURE) set otherwise. We ignore the errors because + can't do anything about them anyways. */ + (void) munlock (guard, guardsize); pd->guardsize = guardsize; }