From nobody Tue Nov 08 11:56:10 2022 X-Original-To: freebsd-arm@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 4N665152slz4V318 for ; Tue, 8 Nov 2022 11:56:21 +0000 (UTC) (envelope-from SRS0=V+t4=3I=klop.ws=ronald-lists@realworks.nl) Received: from smtp-relay-int.realworks.nl (smtp-relay-int.realworks.nl [194.109.157.24]) (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 did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4N66502270z4GXP; Tue, 8 Nov 2022 11:56:20 +0000 (UTC) (envelope-from SRS0=V+t4=3I=klop.ws=ronald-lists@realworks.nl) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=klop.ws header.s=rw2 header.b=MfE3KsAZ; spf=pass (mx1.freebsd.org: domain of "SRS0=V+t4=3I=klop.ws=ronald-lists@realworks.nl" designates 194.109.157.24 as permitted sender) smtp.mailfrom="SRS0=V+t4=3I=klop.ws=ronald-lists@realworks.nl"; dmarc=pass (policy=quarantine) header.from=klop.ws Date: Tue, 8 Nov 2022 12:56:10 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=klop.ws; s=rw2; t=1667908571; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=XFumg3LgVfbGNPgFhc1S/u6V6/DE6/+zrb3J0pppd7o=; b=MfE3KsAZPL6N8XSQUTeD98cwA4toGiQTstomEBZQ/Ca8QNvplu31miblngIH2ELpRefhS3 tiP8DJYLV4lXQiwgPnbwLZu78FsC9mG9M6o72VFeu1ue5GATW1mqZ9krMdeZHQohfPcRmY KFJqrxfQ5s9kzroT//1zrqCD6772JI8QXalC1jCsP8G/xEeonskLDZ5yuXJq+wuXvrBrmA q6IUcABYwdxW9kwDvviJ8bMptFu7utSTSgBPmopQIElmYvnIUlbHg4jutYXZDv2mhA3yxr Q/jMDRvTbGXmYZgUwg008AdWUNBSWr4qzWbjTYeJM2cbR0DEpbp8WfKx8h9tWQ== From: Ronald Klop To: mike@karels.net Cc: jmg@freebsd.org, freebsd-arm@freebsd.org Message-ID: <95847460.127804.1667908570062@localhost> In-Reply-To: <202211071610.2A7GAcHl090048@mail.karels.net> References: <202211071610.2A7GAcHl090048@mail.karels.net> Subject: Re: adding swap when expanding root filesystem List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_127803_560799664.1667908570055" X-Mailer: Realworks (630.39) Importance: Normal X-Priority: 3 (Normal) X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.03 / 15.00]; NEURAL_HAM_SHORT(-1.00)[-0.999]; NEURAL_HAM_LONG(-1.00)[-0.998]; NEURAL_HAM_MEDIUM(-0.83)[-0.832]; DMARC_POLICY_ALLOW(-0.50)[klop.ws,quarantine]; MID_RHS_NOT_FQDN(0.50)[]; FORGED_SENDER(0.30)[ronald-lists@klop.ws,SRS0=V@realworks.nl]; R_SPF_ALLOW(-0.20)[+ip4:194.109.157.0/24]; R_DKIM_ALLOW(-0.20)[klop.ws:s=rw2]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; RCVD_COUNT_ZERO(0.00)[0]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:3265, ipnet:194.109.0.0/16, country:NL]; MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]; ARC_NA(0.00)[]; DKIM_TRACE(0.00)[klop.ws:+]; TAGGED_FROM(0.00)[t4=3I=klop.ws=ronald-lists]; FROM_HAS_DN(0.00)[]; HAS_X_PRIO_THREE(0.00)[3]; RCPT_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_NONE(0.00)[]; FROM_NEQ_ENVFROM(0.00)[ronald-lists@klop.ws,SRS0=V@realworks.nl] X-Rspamd-Queue-Id: 4N66502270z4GXP X-ThisMailContainsUnwantedMimeParts: N ------=_Part_127803_560799664.1667908570055 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Van: Mike Karels Datum: maandag, 7 november 2022 17:10 Aan: freebsd-arm@freebsd.org CC: jmg@freebsd.org Onderwerp: adding swap when expanding root filesystem > > This question is not really arm-specific, but I couldn't think of a better > mailing list for it. > > There are peridic issues reported on small systems like Raspberry Pi > where people are running buildworld or poudriere and running out of > memory. As the user gets no control over the disk layout when installing, > there is no option to add swap space on the install image. I have added > swap space on a USB disk, but this is often not an option. It occurred > to me that it might be reasonable to add swap space before expanding > the root filesystem if there is sufficient space. I have a prototype, > and wondered if this is a good thing to do. Granted, this will often > create swap on microSD, which is not optimal, but probably better than > nothing. > > The current prototype creates a swap partition which is 1/10 of the disk > if the disk is at least 15 GB and the initial root partition is no more > than 1/3 of the disk, but only up to 1.5x of physical memory. I would > probably enable this by default, but provide a way to disable it via a > kenv variable and/or a variable in /etc/rc.conf. > > Thoughts? > > Mike > Hi, Would you mind sharing your prototype? Regards, Ronald. ------=_Part_127803_560799664.1667908570055 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit  

Van: Mike Karels <mike@karels.net>
Datum: maandag, 7 november 2022 17:10
Aan: freebsd-arm@freebsd.org
CC: jmg@freebsd.org
Onderwerp: adding swap when expanding root filesystem

This question is not really arm-specific, but I couldn't think of a better
mailing list for it.

There are peridic issues reported on small systems like Raspberry Pi
where people are running buildworld or poudriere and running out of
memory.  As the user gets no control over the disk layout when installing,
there is no option to add swap space on the install image.  I have added
swap space on a USB disk, but this is often not an option.  It occurred
to me that it might be reasonable to add swap space before expanding
the root filesystem if there is sufficient space.  I have a prototype,
and wondered if this is a good thing to do.  Granted, this will often
create swap on microSD, which is not optimal, but probably better than
nothing.

The current prototype creates a swap partition which is 1/10 of the disk
if the disk is at least 15 GB and the initial root partition is no more
than 1/3 of the disk, but only up to 1.5x of physical memory.  I would
probably enable this by default, but provide a way to disable it via a
kenv variable and/or a variable in /etc/rc.conf.

Thoughts?

        Mike
 


Hi,

Would you mind sharing your prototype?

Regards,
Ronald.

  ------=_Part_127803_560799664.1667908570055--