From owner-freebsd-hackers@freebsd.org Fri Sep 28 15:25:59 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0CC1C10B3436 for ; Fri, 28 Sep 2018 15:25:59 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: from mail-pg1-x52b.google.com (mail-pg1-x52b.google.com [IPv6:2607:f8b0:4864:20::52b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 8639077221 for ; Fri, 28 Sep 2018 15:25:58 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: by mail-pg1-x52b.google.com with SMTP id y18-v6so4741597pge.0 for ; Fri, 28 Sep 2018 08:25:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=PuRHPvO0sy6iH+spu54+WFWVUjEriTRauiHgd5AvejI=; b=pTPje0lfguOoxH1JhhqKXEDLZ34qGuUCa/HJrP3aBPck1O6s86uOy2JhFxQJJtOc+W VNHT/Z5LexmBMZtNb3e0rj4hnHHuHVJCXFziVJ/OAa7EwiaHf66YiR8q4R8AXcfMYTp2 pUxAgNl0YjZVzFwOVq7+e+J6fhwZDhHhImtQWrr466fWHSP5tALaSWjBwlrjOo/LN2Qz ZY6xP8vYmpj/9uIZ1lZ+yEaOhQWY934o/AEWQ25NhNnXqiFrGWp3GG59UPE/CXEnn65l mGB/H7bmUUI81C4Yy1Rawy4O6RNB4csvJ9qvCMhwnRIabWr8Hb5i/ak6H1ba4GNmlyyI pRrA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :references:mime-version:content-disposition:in-reply-to:user-agent; bh=PuRHPvO0sy6iH+spu54+WFWVUjEriTRauiHgd5AvejI=; b=IG2ww3GniT3ijZoZJqx2tYUMpLO1w6sMltnN5obGFtokscKHmZAXTWXNKB9XtxtbCh plS1QX9SkQoCFlSi2N7rvPUZ7vTckhou+wqCue0r4kXZwj3Td7i5XMdO5/iShVY/heK+ QDpezrtRAYyAfTqTZ4YoejTzF0JxGpvj3N03SdDKAXzcyc5AemgrO/cequOf8O33TSKw RjTYsI/NDb0BN+Y1eLGeYWvHmix+XeZKqDRCxrf3uET33jozWVZRP7LXIIqVd/yoLSb1 EmDIefCcrZ1LH4Q35BZGqJJed82CR89nBrSlGgrcNYV0D3+x13z6ntMeGWsiX9oirnxg +R5A== X-Gm-Message-State: ABuFfoi6ZchPeH/BciFD/Jaz5ddXtB1QnZmzR2iuTkBpPFSpPMLNVM// qHsNoyD3Z/4iBZ7tStDry7s= X-Google-Smtp-Source: ACcGV60yP1KWpmoxFI94aA7LGs/Yd5cmRp07zMIKegM/SgOQ/u29W/SdNkRxWVKrqec4bKty9ixHUQ== X-Received: by 2002:a63:f110:: with SMTP id f16-v6mr15560873pgi.236.1538148357292; Fri, 28 Sep 2018 08:25:57 -0700 (PDT) Received: from raichu (toroon0560w-lp130-01-174-88-79-38.dsl.bell.ca. [174.88.79.38]) by smtp.gmail.com with ESMTPSA id 89-v6sm13027231pfk.134.2018.09.28.08.25.55 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 28 Sep 2018 08:25:56 -0700 (PDT) Sender: Mark Johnston Date: Fri, 28 Sep 2018 11:25:50 -0400 From: Mark Johnston To: Robert Cc: freebsd-hackers@freebsd.org Subject: Re: Sudden grow of memory in "Laundry" state Message-ID: <20180928152550.GA3609@raichu> References: <55b0dd7d-19a3-b566-0602-762b783e8ff3@gmail.com> <20180911005411.GF2849@raichu> <20180911150849.GD92634@raichu> <104be96a-c16b-7e7c-7d0d-00338ab5a106@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <104be96a-c16b-7e7c-7d0d-00338ab5a106@gmail.com> User-Agent: Mutt/1.10.1 (2018-07-13) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Sep 2018 15:25:59 -0000 On Thu, Sep 27, 2018 at 04:04:15PM -0700, Robert wrote: > Is there a way to force move pages back from laundry to Free or Inactive? There's no real way to do that from outside of the application. The application itself can free anonymous memory by unmapping it. It can also force memory to be marked clean (thus moving it back to the inactive queue) using madvise(MADV_FREE). This will cause the memory's contents to be discarded, though. > Also, what's the best way to identify addresses of these pages and > "look" inside of them? There's no convenient way to do that that I'm aware of. On amd64, you could in principle use kgdb to dump individual pages in the queue via the direct map: # kgdb82 -q Reading symbols from /boot/kernel/kernel...Reading symbols from /usr/lib/debug//boot/kernel/kernel.debug...done. done. sched_switch (td=0xfffff8002c560000, newtd=0xfffff800025ca000, flags=) at /home/mark/src/freebsd-dev/sys/kern/sched_ule.c:2112 2112 cpuid = PCPU_GET(cpuid); (kgdb) p vm_dom[0].vmd_pagequeues[2] $1 = { pq_mutex = { lock_object = { lo_name = 0xffffffff80c34c0d "vm laundry pagequeue", lo_flags = 21168128, lo_data = 0, lo_witness = 0xfffff8041ed6cb00 }, mtx_lock = 0 }, pq_pl = { tqh_first = 0xfffff8040f9ef980, tqh_last = 0xfffff8041227f448 }, pq_cnt = 20087, pq_name = 0xffffffff80c34c0d "vm laundry pagequeue", pq_pdpages = 0 } (kgdb) x/512gx vm_dom[0].vmd_pagequeues[2].pq_pl.tqh_first->phys_addr + (vm_offset_t)&dmapbase 0xfffff801aea00000: 0x0000000800000000 0x000000082298c400 0xfffff801aea00010: 0x00000009be801000 0x0000000000000006 ...