From owner-freebsd-hackers@freebsd.org Wed May 24 08:00:54 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1ADC4D7BDF1 for ; Wed, 24 May 2017 08:00:54 +0000 (UTC) (envelope-from shrikanth07@gmail.com) Received: from mail-qt0-x232.google.com (mail-qt0-x232.google.com [IPv6:2607:f8b0:400d:c0d::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id CEC7319EE for ; Wed, 24 May 2017 08:00:53 +0000 (UTC) (envelope-from shrikanth07@gmail.com) Received: by mail-qt0-x232.google.com with SMTP id c13so148631302qtc.1 for ; Wed, 24 May 2017 01:00:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=zHvN2eN4lkybiMRNjEzDSpBZFM25xxAfIo80CU8PopA=; b=X1JDlsJTamtCSW2Op4oI+k8+xf/XnHmxB2s+6knNAPUczLmUSDEU37rBKMahN8LfFu 3whEkM6P/S7aGsSJzGNOlLIF5FBgvXgz7Xv/lXrteT4Pm08P+QVtgFwqag576R8b22dx 4RAAR9JxaDTvB+lnXXthm9LjLFvUgzYuUSUE/QwKtirGH1BOonGvZh/eICA6MFN2iBXf fZMv0FPD8g9HaEiXWY3cal3pVAw73uq9gGfST7uHz62D3l1jrv9e1Ag+7QKNsqrTUZih nUltFoe+C4/4EU7VjBSBRg6dm83NVB7GUFwK2hoyKjyILv7QKsVK8PRa1EDYVrfGRLHr X4wg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=zHvN2eN4lkybiMRNjEzDSpBZFM25xxAfIo80CU8PopA=; b=IDhixnu6brJ/EnKQAr+0DLUO+oGEWrnBW9bTfIG0U6NdJkQjIa00jPLBV4n7KR5VTE gYIoiUcLcPkNO5+UfYaCJuL/Hu5mEGyrYu+pXJcLgu6uj5KvxYH+dmxcAT29OwYYdTtl IVNHkbjdqPeLsjK19H97dHttbKpYSppa77/DqBHjutNNjfKTSUVmBVdg61i3tjVpW/HM jEd3QVIGxquJu27pDNWYz+BgtC1xK9uDCPoJvlrZTyUbaZ2ddlPuccBkOjrBQc6QNl68 520O1GM2bhf5UMr7HeOEPg5m53asD3Jca15gFvQvTZkMkk8JBD48BkjwjMqTSchKVWOn gCyg== X-Gm-Message-State: AODbwcDC0triYMCdiXrji7d1/bXjQ6x5NPqJDe0BlQYdfBBWasVXrO86 EcoEm2gcsWujafehJdKyr7HDkzMXLbu5 X-Received: by 10.200.40.46 with SMTP id 43mr33988746qtq.132.1495612852314; Wed, 24 May 2017 01:00:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.38.241 with HTTP; Wed, 24 May 2017 01:00:51 -0700 (PDT) From: Shrikanth Kamath Date: Wed, 24 May 2017 01:00:51 -0700 Message-ID: Subject: Difference between p_vmspace quota between stable/11 and stable/10 To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 May 2017 08:00:54 -0000 I have a certain application(32 bit user space running in compat mode in 64 bit system X86) which does a fork, and the child process does a series of mmap calls as part of a scaling test. I am currently debugging an issue with this application which hits a ENOMEM when it is run on a stable/11 based setup and fails subsequent mmap and/or any malloc calls v/s stable/10 where the issue is not seen.. I probed the vm_map_find function using DTrace when "execname" was my application in question, and got these readings fbt:kernel:vm_map_find:entry /self->trace == 1/ /*enabled only during sys_mmap call of this application */ { @bytes[args[4]] = sum(args[4]); printf("request length [%x]", args[4]); } For stable_10 --> Total of 124 requests (length requested was 0x500000) with the test successful 124 * 0x500000 (5MB) ~ 620MB For stable_11 --> Total of 109 mmap requests (0x500000/0x200000/0x3ff000 are the different vm_size_t length arguments in vm_map_find). The test fails after 386MB has been approved. 24 * 0x500000 (5MB) ~ 120MB 82 * 0x200000 (2MB) ~ 164MB 3 * 0x3ff000 (4MB) ~ 12MB The process parent rlimits are # cat /proc/5058/rlimit cpu -1 -1 fsize -1 -1 data 3221225472 3221225472 stack 16777216 16777216 core -1 -1 rss 67108864 33265819648 memlock 67108864 33265819648 nproc 512 512 nofile 1024 1024 sbsize -1 -1 vmem -1 -1 npts -1 -1 swap -1 -1 kqueues -1 -1 umtx -1 -1 The requests started failing in stable/11 with just 386 MB approved v/s stable/10 which was successful in approving ~620MB. My stable/11 is from early days and is at GRN 302410 (probably 10 months old) Any pointers or tips on what to probe further will be very helpful. Is there any limits breach that I should probe further? The limits set when a process is forked? Should I probe the p->vmspace initiazliation? Thanks, -- Shrikanth R K