From nobody Mon Jul 10 23:26:58 2023 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4R0KsR6jwyz2tkmW for ; Mon, 10 Jul 2023 23:27:07 +0000 (UTC) (envelope-from pete@nomadlogic.org) Received: from mail.nomadlogic.org (mail.nomadlogic.org [66.165.241.226]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "mail.nomadlogic.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4R0KsQ6Rhxz3wRq for ; Mon, 10 Jul 2023 23:27:06 +0000 (UTC) (envelope-from pete@nomadlogic.org) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=nomadlogic.org header.s=04242021 header.b=U2+eh0O1; spf=pass (mx1.freebsd.org: domain of pete@nomadlogic.org designates 66.165.241.226 as permitted sender) smtp.mailfrom=pete@nomadlogic.org; dmarc=pass (policy=quarantine) header.from=nomadlogic.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nomadlogic.org; s=04242021; t=1689031621; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=7fcXbDzmM38azzg46efgP31H2ZO1B72f4ulGDTXrqyc=; b=U2+eh0O1e1PHRYN4xsJc+Vg0dC00J3u/rTZX5h6RLOAjfsEAAFt6JpR8oosG/dEwlZS9Qi qqi9T7z2viWAwPIxR7DhBdDJnyjC7GLNqIsB7RWNpwA86Vm8C764saD5+2L8Wj48WuwRgj z3EqxcGEmey3fPe4VeVInmps9LMLRWo= Received: from [192.168.1.240] (cpe-24-24-168-214.socal.res.rr.com [24.24.168.214]) by mail.nomadlogic.org (OpenSMTPD) with ESMTPSA id 4cdf75a5 (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO) for ; Mon, 10 Jul 2023 23:26:58 +0000 (UTC) Message-ID: Date: Mon, 10 Jul 2023 16:26:58 -0700 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0) Gecko/20100101 Thunderbird/102.13.0 Subject: Re: huge amount laundry memory not being cleaned up To: freebsd-current@freebsd.org References: Content-Language: en-US From: Pete Wright In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spamd-Result: default: False [-3.99 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.99)[-0.985]; DMARC_POLICY_ALLOW(-0.50)[nomadlogic.org,quarantine]; R_SPF_ALLOW(-0.20)[+mx]; R_DKIM_ALLOW(-0.20)[nomadlogic.org:s=04242021]; MIME_GOOD(-0.10)[text/plain]; DKIM_TRACE(0.00)[nomadlogic.org:+]; ASN(0.00)[asn:29802, ipnet:66.165.240.0/22, country:US]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; MIME_TRACE(0.00)[0:+]; FROM_EQ_ENVFROM(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; MID_RHS_MATCH_FROM(0.00)[]; ARC_NA(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_HAS_DN(0.00)[]; TO_DN_NONE(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; RCVD_TLS_ALL(0.00)[] X-Rspamd-Queue-Id: 4R0KsQ6Rhxz3wRq X-Spamd-Bar: --- X-ThisMailContainsUnwantedMimeParts: N On 7/10/23 4:01 PM, Mark Millard wrote: > Pete Wright wrote on > Date: Mon, 10 Jul 2023 19:35:26 UTC : > >> hi there, >> i've got a workstation running CURRENT that recently ran out of swap >> space. i killed the usual suspects (chrome, firefox and thunderbird) >> and noticed some odd behavior. while some memory did get freed up - >> after leaving the system idle for 4 hours i still have 14G or memory in >> the Laundry according to top. I also have noticed that very little data >> has paged out of swap (100MB out of 2G). >> >> >> i was wondering if there was a good way to determine what is in the >> laundry, > > I do not know how to get a breakdown of the laundry's usage. > But I'd expect, say, for example, top's resident memory > figures would count what is in the laundry as resident. > If correct, given the large laundry usage, may be some > resident figures would be suggestive? thanks Mark, so yea i poked around and didn't see any large consumers of resident memory. > >> or get diagnostic info on why it's not cleaning itself up? > > As I understand, it would take take one of the following > to change the status of the pages in the laundry in normal > operation: > > A) access to a page by a program, turning the page into > being in the active category. (It might go through > inactive to get there?) > > B) memory pressure leading to sending the page to the swap > in order to provide a page for a different use. > > Time alone does not contribute much as I understand. More > on-demand driven. Laundry is sort of "inactive but known > to be dirty" as I understand, in some respects just a > subset of inactive optimized for being closer to ready to > page out to swap space if needed. i'm doing a build world now since i'll need to reboot this box anyway, just to get everything up to date. interestingly enough i'm still pegged at 14G of laundry memory, and my 2G swap is %100 utilized. once the build world completes i'll do a double check and see if i can find any large consumers of resident memory which may lead me in the right direction. cheers! -pete -- Pete Wright pete@nomadlogic.org