Re: [PATCH] Convert the VFS cache lock to an rmlock

On Thu, Mar 12, 2015 at 06:13:00PM -0500, Alan Cox wrote: > Below is partial results from a profile of a parallel (-j7) "buildworld" on > a 6-core machine that I did after the introduction of pmap_advise, so this > is not a new profile. The results are sorted by total waiting time and > only the t

Jenkins build is back to normal : FreeBSD_HEAD #2534

See ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: [PATCH] Convert the VFS cache lock to an rmlock

Below is partial results from a profile of a parallel (-j7) "buildworld" on a 6-core machine that I did after the introduction of pmap_advise, so this is not a new profile. The results are sorted by total waiting time and only the top 20 entries are listed. max wait_max total wait_to

Build failed in Jenkins: FreeBSD_HEAD #2533

See Changes: [nwhitehorn] Provide VSX context in ucontext(3) API. [kib] Remove write-only variable. Sponsored by: The FreeBSD Foundation MFC after: 3 days [ae] Add GUID and alias for Apple Core Storage partition. PR:

Build failed in Jenkins: FreeBSD_HEAD #2532

See Changes: [ian] Nullterminate strings returned via sysctl. PR: 195668 [ian] Nullterminate strings returned via sysctl. PR: 195668 [ian] Nullterminate strings returned via sysctl. PR: 195668 [j

Re: [PATCH] Convert the VFS cache lock to an rmlock

On Thu, Mar 12, 2015 at 11:14:42AM -0400, Ryan Stone wrote: > I've just submitted a patch to Differential[1] for review that converts the > VFS cache to use an rmlock in place of the current rwlock. My main > motivation for the change is to fix a priority inversion problem that I saw > recently.

Re: [PATCH] Convert the VFS cache lock to an rmlock

On Thu, Mar 12, 2015 at 12:37 PM, Adrian Chadd wrote: > Do you have access to any boxes that have more than 12 cores? I have a 14-core hyperthreaded machine (so 28 logical cores), but it has no disk (long story). I could do a build out of a memory disk though. Also, to ask a stupid question - w

Re: [PATCH] Convert the VFS cache lock to an rmlock

Also, to ask a stupid question - why wasn't the reader gifted a temporary priority boost because you were trying to acquire the write lock? -adrian ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current T

Re: [PATCH] Convert the VFS cache lock to an rmlock

Do you have access to any boxes that have more than 12 cores? (like 36, 64, 80+ ?) -adrian On 12 March 2015 at 08:14, Ryan Stone wrote: > I've just submitted a patch to Differential[1] for review that converts the > VFS cache to use an rmlock in place of the current rwlock. My main > motiva

[PATCH] Convert the VFS cache lock to an rmlock

I've just submitted a patch to Differential[1] for review that converts the VFS cache to use an rmlock in place of the current rwlock. My main motivation for the change is to fix a priority inversion problem that I saw recently. A real-time priority thread attempted to acquire a write lock on the

Jenkins build is back to normal : Build-UFS-image #1335

See ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Build failed in Jenkins: Build-UFS-image #1334

Hi Craig! > On Mar 12, 2015, at 08:17, jenkins-ad...@freebsd.org wrote: > > See echo /builds/FreeBSD_HEAD/obj/builds/FreeBSD_HEAD/sys/boot/amd64/boot1.efi > /builds/FreeBSD_HEAD/obj/builds/FreeBSD_HEAD/sys/boot/amd64/boot1.efi > uudec

Build failed in Jenkins: Build-UFS-image #1334

See -- [...truncated 17069 lines...] Australia/Darwin Australia/Sydney Australia/Brisbane Australia/Broken_Hill Australia/Lindeman Australia/Currie Australia/Lord_Howe Australia/Hobart Australia/Perth A

Re: Extending PATH variable in top-level Makefile

On 03/11/15 17:38, Brooks Davis wrote: On Wed, Mar 11, 2015 at 11:21:17AM +0100, Hans Petter Selasky wrote: Hi, When installing bmake from ports, the binary ends up in /usr/local/bin and our top-level Makefile doesn't check there: diff --git a/Makefile b/Makefile index e89a5b1..35ade48 100644