how to recycle Inact memory more aggressively?
In the course of the last year or so the behavior of the vm system has changed in regard to how aggressively Inact memory is recycled. My box has 8GB of memory. At the moment I'm copying 100s of gigabytes from one file system to another one. Looking at top I observe that there are about 6GB of Inact memory. This value hardly changes. Instead of aggressively recycling the Inact memory the vm now seems to prefer to swap. Last year, can't rmember excatly when, the behavior was totally different. The vm very aggessively recycled Inact memory and, even when copying 100s of GB of files, the system hardly swapped. It seems rather strange to me that the vm happily allows gigbytes of Inact memory to be present and prefers swapping to recyclincg. Are there any sysctl's I can set to get the old behavior back? -- Gary Jennejohn ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: FreeBSD_HEAD_amd64_gcc4.9 - Build #1120 - Still Failing
On 10 Mar 2016, at 03:38, Bryan Drewery wrote: > > On 3/9/2016 1:48 AM, jenkins-ad...@freebsd.org wrote: >> FreeBSD_HEAD_amd64_gcc4.9 - Build #1120 - Still Failing: >> >> Build information: >> https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_amd64_gcc4.9/1120/ >> Full change log: >> https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_amd64_gcc4.9/1120/changes >> Full build log: >> https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_amd64_gcc4.9/1120/console ... > This seems to be from the clang upgrade. It's now fixed, after r296687: https://jenkins.freebsd.org/job/FreeBSD_HEAD_amd64_gcc4.9/1123/ Btw, this job should really be upgraded to use gcc 5.3.0, like the devel/amd64-xtoolchain-gcc port provides. -Dimitry signature.asc Description: Message signed with OpenPGP using GPGMail
FreeBSD_HEAD_amd64_gcc4.9 - Build #1123 - Fixed
FreeBSD_HEAD_amd64_gcc4.9 - Build #1123 - Fixed: Build information: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_amd64_gcc4.9/1123/ Full change log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_amd64_gcc4.9/1123/changes Full build log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_amd64_gcc4.9/1123/console Change summaries: 296718 by trasz: Use S_BLKSIZE instead of magic constant. MFC after: 1 month Sponsored by: The FreeBSD Foundation 296717 by trasz: Refactor the way we restore cn_lkflags; no functional changes. MFC after: 1 month Sponsored by: The FreeBSD Foundation 296716 by trasz: Remove cn_consume from 'struct componentname'. It was never set to anything other than 0. Reviewed by:kib@ MFC after: 1 month Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D5611 296715 by trasz: Fix autofs triggering problem. Assume you have an NFS server, 192.168.1.1, with share "share". This commit fixes a problem where "mkdir /net/192.168.1.1/share/meh" would return spurious error instead of creating the directory if the target filesystem wasn't mounted yet; subsequent attempts would work correctly. The failure scenario is kind of complicated to explain, but it all boils down to calling VOP_MKDIR() for the target filesystem (NFS) with wrong dvp - the autofs vnode instead of the filesystem root mounted over it. Reviewed by:kib@ MFC after: 1 month Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D5442 296714 by jhb: Remove Symbol.map entries for old AIO system calls for FreeBSD 6 compat. These entries should have never been present since they only exist for compat with FreeBSD 6.x (and older) binaries. This was missed in r296572. Technically this breaks the ABI by removing versioned symbols. However, no binaries should be linked against these symbols. No release has shipped with a header that contained a prototype for these functions. Reviewed by:kib Differential Revision: https://reviews.freebsd.org/D5615 296713 by andrew: Print the correct size of loader.efi when failing to load it into memory. Obtained from: AsiaBSDCon Sponsored by: ABT Systems Ltd 296711 by np: cxgbe(4): Fix typo in previous commit. 296710 by np: cxgbe(4): Catch up with the latest list of card capabilities as reported by the firmware. 296709 by bdrewery: Move Makefile.lib32 to Makefile.libcompat and generalize it. This is in preparation for LIBSOFT. This file only supports *1* LIBCOMPAT value currently and must be capitalized. In Makefile.libcompat given LIBCOMPAT=FOO there can be values set for LIBFOOCFLAGS, LIBFOOCPUFLAGS, LIBFOOWMAKEENV, LIBFOOWMAKEFLAGS, LIBFOOCPUFLAGS, and LIBFOODTRACE. These will have the standard cross-build values appended onto them. This could be extended to support multiple libcompat libraries in the future once there is a need. Reviewed by:imp Sponsored by: EMC / Isilon Storage Division Differential Revision: https://reviews.freebsd.org/D5612 296708 by bdrewery: DIRDEPS_BUILD: Update dependencies. Sponsored by: EMC / Isilon Storage Division 296707 by bdrewery: Add missing CLEANFILES. MFC after: 1 week Sponsored by: EMC / Isilon Storage Division 296706 by bdrewery: Add more .NOMETA missed in r291320 Sponsored by: EMC / Isilon Storage Division 296705 by bdrewery: Revert r269030. CLEANFILES is already added to .NOPATH since r241298. Sponsored by: EMC / Isilon Storage Division 296704 by bdrewery: Remove bogus .ORDER. This is not SUBDIR_PARALLEL and if it were this .ORDER would not work since the targets are _subdir_ not . MFC after: 1 week Sponsored by: EMC / Isilon Storage Division 296703 by bdrewery: Don't even define or append subdir targets with NO_SUBDIR. No functional change. This prevents adding empty targets to the main called target which is confusing for debugging. MFC after: 2 weeks Sponsored by: EMC / Isilon Storage Division 296702 by bdrewery: Remove exists() checks so normal out-of-date handling can be used. This also fixes META MODE rebuilding these because the 'number of build commands' changed from the previous build. MFC after: 2 weeks Sponsored by: EMC / Isilon Storage Division 296701 by bdrewery: META_MODE: We can only use a cookie if filemon is being used. Sponsored by: EMC / Isilon Storage Divsion 296700 by bdrewery: META_MODE: Simplify the META_COOKIE handling to use .USE/.USEBEFORE. Extend it to other cases of meta mode cookies so they get the proper rm cookie behavior when a .meta file detects it needs to rebuild and fails. Sponsored by: EMC / Isilon Storage Division 296699 by bdrewery: DIRDEPS_BUILD: Add a sure way to prohibit building 'all' during dirdeps phase. This obsoletes the _SKIP_BUILD check but keeps it for now until it proves to be enough. In the dirdeps build the first 'make all' or 'make' ran would invoke 'make dirdeps' which builds dependencies and then builds the cu
UPDATING revision and seperate edge-case question(s)
Having unexpectedly built world and kernel GENERIC on 3-8 Current, that is not the principal system [1] ... browsing its UPDATING at the bottom the method(s) are not so precise and/or informative [follows...] [make world] make kernel installworld where is installkernel make buildworld make kernel mm... make installworld mm... where is installkernel but in motd where I save howtos backups check nosuid gone make buildworld make buildkernel single user mm... [take good notes] installworld ... and for a lack of time, have to put it all on paper (several draft revisions within motd ) and in another /usr/src-old svn sources move make.conf check nosuid buildworld buildkernel [ compare GENERICS assumed], add compatN etc installkernel mergemaster first type, using /usr/src/.../mergemaster.sh single-user (yet) installworld mergemaster (complete ) install newly needed compatNif necc. make delete-old ( and sometimes a pipe y | make... or something) restore nosuid restore make.conf rebuild nvidia-driver etc if necc. AND steps I often take that I've not listed... So, the latter example is more complete than the ones before it However, I think other things may be missing what if it should include a 2a make distribution 2b... make release etc which I have no experience with... / end of requested another section in UPDATING with commented more-complete steps from someone with more knowledge than I... . [1] Edge case... buildworld/kernel on another machine that is/was backup except that it ran out of space on a few filesystems, so is NOT backup... wishing for a foolproof method to script its expected installkernel/installworld onto an attached main-os disk, something with rsync... to expedite recovery from the main-os disk installworld that fails at some point midway, meaning directory-by-directory fixes using cp, gcp, rsync until the hosed installworld is usable again (I've done it before, that is why I am asking for a feature that will preclude the installworld failure, something like /work/ /stage/ in ports, where the /stage-installworld/ has been tested every which way so that if the stage-installworld completes, the regular installworld is guaranteed to complete. Seeming about a half-years work on someone's part, just adding this edge case in case someone has perchance crafted something similar, would jumpstart something similar as a feature, and/or explain an equivalent methodology, to increase the reliability of updating a system, say upon a critical security advisory happening to every os on the web all at once... ... ASKING NO RESPONSE to this email to here, do not wish to waste anyone's time, just to put forth a few ideas... .. Thanks for reading. J. Bouquet ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [CFT] packaging the base system with pkg(8)
Daniel Eischen writes: > It would be nice to have pkg(8) show packages in tree form, with option > to show just top-level meta packages or packages that have no meta. Packages not marked as automatically installed: # pkg query -e '%a == 0' %n-%v Packages with no reverse dependencies: # pkg query -e '%#r == 0' %n-%v DES -- Dag-Erling Smørgrav - d...@des.no ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Fwd: Re: UPDATING revision and seperate edge-case question(s)
Sorry, sent it to this same email originally, on to the list... - Start Forwarded Message - Sent: Sat, 12 Mar 2016 17:33:31 -0800 (PST) From: "Jeffrey Bouquet" To: "jbtakk" Subject: Re: UPDATING revision and seperate edge-case question(s) Just for completeness, the buildworld draft section I wrote below..., three were missing at least... though still a rough draft... Approximately seven lines added/revised... On Sat, 12 Mar 2016 08:10:22 -0800 (PST), "Jeffrey Bouquet" wrote: > Having unexpectedly built world and kernel GENERIC on 3-8 Current, that is not > the principal system [1] ... browsing its UPDATING at the bottom the > method(s) are > not so precise and/or informative [follows...] > > [make world] > make kernel > installworld > where is installkernel > > make buildworld > make kernel > mm... > make installworld > mm... > where is installkernel > > but in motd where I save howtos > > backups > check nosuid gone > make buildworld > make buildkernel > single user > mm... [take good notes] > installworld > > ... and for a lack of time, have to put it all on paper (several draft > revisions > within motd ) > > and in another /usr/src-old > READ UPDATING > svn sources > move make.conf > check nosuid > buildworld COMPARE NEWEST GENERIC WITH PRIOR GENERIC IF CUSTOM AND/OR NOT KERNEL > buildkernel [ compare GENERICS assumed], add compatN etc > installkernel sh /usr/src/usr.sbin/mergemaster/mergemaster -vipPc (-F?)# revised > reboot single-user (yet) mount -t ufs -u -o rw /dev/gpt/label /(or whatever) # new mount -va #new df# new > installworld > another mergemaster if necc # revised > install newly needed compatNif necc. > yes | make delete-old # > revised yes | make delete-old-libs# revised > restore nosuid > restore make.conf > rebuild nvidia-driver etc if necc. > > AND steps I often take that I've not listed... # some in > revision > > So, the latter example is more complete than the ones before it > However, I think other things may be missing # see > revisions for example > what if it should include a 2a make distribution 2b... make release etc > which I have no > experience with... > > / end of requested another section in UPDATING with commented more-complete > steps from > someone with more knowledge than I... > . > [1] > > Edge case... > buildworld/kernel on another machine that is/was backup except that it ran > out of space > on a few filesystems, so is NOT backup... > wishing for a foolproof method to script its expected > installkernel/installworld onto an > attached main-os disk, something with rsync... to expedite recovery from the > main-os > disk installworld that fails at some point midway, meaning > directory-by-directory fixes > using cp, gcp, rsync until the hosed installworld is usable again (I've done > it before, that > is why I am asking for a feature that will preclude the installworld failure, > something like > /work/ /stage/ in ports, where the /stage-installworld/ has been tested every > which way > so that if the stage-installworld completes, the regular installworld is > guaranteed to > complete. > Seeming about a half-years work on someone's part, just adding this edge case > in > case someone has perchance crafted something similar, would jumpstart > something > similar as a feature, and/or explain an equivalent methodology, to increase > the > reliability of updating a system, say upon a critical security advisory > happening to > every os on the web all at once... > > ... > ASKING NO RESPONSE to this email to here, do not wish to waste anyone's time, > just > to put forth a few ideas... > .. > Thanks for reading. > > J. Bouquet > > > ___ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" - End Forwarded Message - ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [CFT] packaging the base system with pkg(8)
On 3/11/16 9:01 AM, Daniel Eischen wrote: > On Fri, 11 Mar 2016, Slawa Olhovchenkov wrote: > >> On Fri, Mar 11, 2016 at 01:05:11PM +0100, Baptiste Daroussin wrote: >> >>> On Tue, Mar 08, 2016 at 05:35:59PM +, David Chisnall wrote: On 8 Mar 2016, at 15:14, Slawa Olhovchenkov wrote: > In terms of comparing packages, if you’re doing that visually then you are likely to have problems anyway, unless your eyes and brain work far better than most humans. We can make that much easier by providing libxo output in pkg and allowing you to have a simple jq script that tells you what the differences are. >>> pkg can already expose the entire content of a package in json or ucl >>> via: >>> $ pkg info --raw --raw-format [json|json-conpact|yaml|ucl] name >> >> Exposing the entire content of a package is not a root of cause. >> Question in comapring of two different setup with different behaviour >> and search cause of difference. >> >> Case of only a few monolitic packages is essentiality simple then case >> of 1000 combined packages. > > It would be nice to have pkg(8) show packages in tree form, with option > to show just top-level meta packages or packages that have no meta. > > Perhaps this is possible, but it's not obvious to me. > https://github.com/freebsd/pkg/blob/master/scripts/pkg_tree.sh -- Regards, Bryan Drewery ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
